Open APIs

1. what type of call is to be used? Should it be GET or POST? or combination of both?
2. How to pass the search service details and address details to the GET request? as per the documentation it is not accepting any request header params other than id
3. Can we get the examples of request and response params for both GET and POST?

Attachment(s)

TMF645_Service_Qualification_Management_API_User_Guide_v4...0   1.14 MB 1 version

{
  "description": "Query Service Qualification POST Illustration",
  "expectedQualificationDate": "2020-04-13T13:51:41.218Z",
  "instantSyncQualification": false,
  "relatedParty": [
    {
      "id": "456",
      "href": "http://serverlocation:port/partyManagement/v4/party/456",
      "name": "Lakshmi",
      "role": "Requester",
      "@type": "RelatedParty",
      "@referredType": "Individual"
    }
  ],
  "searchCriteria": {
    "id": "1",
    "category": {
      "id": "1",
      "href": "http://serverlocation:port/serviceCatalogManagement/v4/category/1",
      "name": "Internet Access",
      "@type": "Category"
    },
    "service": {
      "place": [
        {
          "role": "Installation Place",
          "@type": "GeographicAddress",
          "city": "San Francisco",
          "postcode": "94121",
          "streetName": "25th",
          "streetType": "Avenue",
          "streetNr": "437"
        }
      ]
    },
    "@type": "SearchCriteria"
  },
  "@type": "QueryServiceQualification"
}
​

• Can't I query for a list of categories/services at a time for a given address? is there a different service for this purpose?
• Or can I query for all available services at a particular address?
• How to identify whether a category is serviceable at an address? Is it like if a category is serviceable then only it is mentioned in the response?
• How do I know if a POST is acknowledged? in the user guide state is mentioned as acknowledged but in the life cycle of state, this value is not avaialble.

{  "description": "Query Service Qualification POST Illustration",  "expectedQualificationDate": "2020-04-13T13:51:41.218Z",  "instantSyncQualification": false,  "relatedParty": [    {      "id": "456",      "href": "http://serverlocation:port/partyManagement/v4/party/456",      "name": "Lakshmi",      "role": "Requester",      "@type": "RelatedParty",      "@referredType": "Individual"    }  ],  "searchCriteria": {    "id": "1",    "category": {      "id": "1",      "href": "http://serverlocation:port/serviceCatalogManagement/v4/category/1",      "name": "Internet Access",      "@type": "Category"    },    "service": {      "place": [        {          "role": "Installation Place",          "@type": "GeographicAddress",          "city": "San Francisco",          "postcode": "94121",          "streetName": "25th",          "streetType": "Avenue",          "streetNr": "437"        }      ]    },    "@type": "SearchCriteria"  },  "@type": "QueryServiceQualification"}​

• You can query on one category via QueryServiceQualification (with QueryServiceQualification.searchCriteria.category=<<your_category>>
• You can query a list of service via CheckServiceQualification - one service.serviceSpecification per CheckServiceQualification.CheckServiceQualificationItem
• You can query all service at a address QueryServiceQualification (with QueryServiceQualification.searchCriterai.service.place=<<address>>
• You cannot make a request to check only a category - It is always service in the response (You cannot ask "is internet category eligible?" but you can ask "Which serviceSpec from internet category are eligible?)
• As client, you can ask to have the qualification directly in the response (instantSyncQualifcation=true). If not then you have a state to follow progress for the qualification. We have an issue with the acknowledged probably (it is accepted in the swagger). when the qualification is performed the status is 'done'. You have the capability to manage event to let us know subscriber about qualification performed.

{  "description": "Query Service Qualification POST Illustration",  "expectedQualificationDate": "2020-04-13T13:51:41.218Z",  "instantSyncQualification": false,  "relatedParty": [    {      "id": "456",      "href": "http://serverlocation:port/partyManagement/v4/party/456",      "name": "Lakshmi",      "role": "Requester",      "@type": "RelatedParty",      "@referredType": "Individual"    }  ],  "searchCriteria": {    "id": "1",    "category": {      "id": "1",      "href": "http://serverlocation:port/serviceCatalogManagement/v4/category/1",      "name": "Internet Access",      "@type": "Category"    },    "service": {      "place": [        {          "role": "Installation Place",          "@type": "GeographicAddress",          "city": "San Francisco",          "postcode": "94121",          "streetName": "25th",          "streetType": "Avenue",          "streetNr": "437"        }      ]    },    "@type": "SearchCriteria"  },  "@type": "QueryServiceQualification"}​

• Determined by the specific implementation for all invocations of a specific task - this would be expected to be documented by the implementation,
• Determined by the API spec itself - implementations should not deviate from this (I'm not sure if we have any practical example, although prepay balance operations would seem to be good candidates for always being synchronous)
• Determined by the consumer per task invocation, as in this example of service qualification where there is an input flag
• Determined by the provider per task invocation (e.g. we could conceive that address validation might be immediate where the address is found in a GIS, but if it is not found there might be manual work needed to complete the validation or reject it).

• If the task execution is asynchronous, the task must be persisted, since we need to track its execution (either by polling its status or by listening to status change events)
• If the task execution is synchronous, the API implementation may decide nevertheless to persist the task, e.g. for auditing or accounting reasons, or not to persist the task.

• If the implementation decided to persist, the HTTP response will be 201 Created, and the returned task resource should include ID and HREF so that a subsequent GET can be used to retrieve (BTW no guarantees on how long the resource will remain in persistence before being cleaned up.
• If the implementation decided not to persist, the HTTP response will be 200 Success, and the returned task resource will have empty ID and HREF, there is no meaning in this case for a subsequent GET