invoice API semantic mismatch to OASIS 1.0

[monkeypants]

There are two kinds of semantic mismatch between the current /invoice/ swagger spec and the OASIS/UBL eInvoicing spec.

1. Superfluous verbs. Don't need GET, PUT and DELETE /invoice/ endpoints. GET makes sense (processing state metadata) but it's not in the spec (enhancement proposal? - see Enhancement Proposal: GET linked invoice/ACK metadata #6).
2. Missing ACK noun (/business_response/?). These should also be POSTed (it takes two to tango).

Both POSTs should probably return a GUID (for out of band status enquiry now, and possible future GET status/processing-metadata enquiry).

And, aren't there subtypes of invoice noun? should they have their own POST endpoints? I think it might be nicer to map validation rules to endpoints, but they could also be tested against payload types.

[onthebreeze]

Please

• get rid of the DELETE/invoices/{ID} and PUT/invoices/{ID} and GET/Invoices methods - leaving just the POST /invoices and GET /invoice/{ID} methods
• update the POST/invoices method to return an ID GUID (which can subsequently be used for the GET)
• add a POST /responses method with the following structure. The method should return a GUID

{
   "UBLVersionID": "2.1",
   "CustomizationID": "urn:www.digitalbusinesscouncil.com.au:dbc:invoicing:documents:core invoice:xsd::core invoice 1##urn:www.digitalbusinesscouncil.com.au:dbc:einvoicing:process:einvoicing01:ver1.0",
   "ProfileID":"urn:www.digitalbusinesscouncil.com.au:dbc:einvoicing:ver1.0",
   "ID": "B65830",
   "IssueDate": "2005-11-20",
   "SenderParty": {
    "Party": {
      "PartyIdentification": {
            "ID": {
               "schemeID": "ABN",
               "schemeAgencyID": "0151",
               "value": "63197439746"
              } },
      "PartyName": {
        "Name": "Shared Services Centre"
      } },
   "ReceiverParty": {
    "Party": {
      "PartyIdentification": {
            "ID": {
               "schemeID": "ABN",
               "schemeAgencyID": "0151",
               "value": "34132141612"
              } },
      "PartyName": {
        "Name": "Three Steps Pty Ltd"
      } },
   "DocumentResponse": {
      "DocumentReference": {
         "ID": "A00095678",
         "IssueDate": "2005-11-20",
         "DocumentTypeCode": "Invoice"
      },
      "Response": {
         "ResponseCode":  "BusinessReject",
         "Description": "No supporting order or contract"
      }
   }
}

[patilgirish]

@onthebreeze , @monkeypants - I have made the above changes, Please review - https://swaggerhub.com/api/ausdigital/invoice/0.1