8 Service APIs
This section provides a reference for APIs that should be implemented by this Building Block.
Last updated
Was this helpful?
1.0.1
This section provides a reference for APIs that should be implemented by this Building Block.
Last updated
Was this helpful?
The provides additional information on how 'adaptors' may be used to translate an existing API to the patterns described here. This section also provides guidance on how candidate products are tested and how GovStack validates a product's API against the API specifications defined here.
The tests for the Information Mediator Building Block can be found in .
The majority of functions provided by the Information Mediator Building Block are either defined in the “service access flow” or configured by the administrator via the web User Interface. There is, however, a “Directory Service” which can provide listings of clients, methods, and available API specifications for services on the Information Mediator. The directory is managed by admins of members. The directory service centralizes and offers knowledge of all enrolled members and their services along with the information necessary to bind a third-party application as a consumer of that service. These services are described here:
and changes to the API definitions can be made by submitting a pull request on this repository. Additional APIs may be implemented by the Building Block, but the listed APIs define a minimal set of functionality that should be provided by any implementation of this Building Block.The is available.
The services can be accessed via the following Service APIs:
The full API definition of all available services can be produced from the set of all available OpenAPI descriptions. For that one need in all occurrences of:
“path”: { “<some-value>”: … }
prepend <some-value> with
{GovStackInstance}/{memberClass}/{member}/{application}/{service}/ extending this way the path with these details.
At development time, to see which organizations are available on GovStack, an administrator of application A sends a GET request to the security server: url-of-local-information-mediator-security-server/r1/listClients
The response is an array of organizations with descriptions. API MAY implement paging of output.
At development time, an administrator at application A sends a GET request to the security server: url-of-local-information-mediator-security-server/r1/INDIA/GOV/MEMBER/APPLICATION/{listMethods || allowedMethods}
The response is an array of services (either all services or services that the requester is authorized to access via “allowedMethods”). API MAY implement paging of output.
At development time, to learn about an available service, an administrator at application A sends a GET request to the security server: url-of-local-information-mediator-security-server/r1/INDIA/GOV/MEMBER/APPLICATION/getOpenApi?serviceCode=SERVICE
The response is an OpenAPI specification, detailing the endpoints and requirements for that service/API of the requested Service of Application.
To broadcast a message to a Room, the service access API must be followed and the service requested must be the service implementing event type.
At development time, to learn about an available service, an administrator at application A sends a GET request to the security server: url-of-local-information-mediator-security-server/r1/INDIA/GOV/MEMBER/APPLICATION/getOpenApi?serviceCode=SERVICE
The response is an OpenAPI specification, detailing the endpoints and requirements for that service/API of the requested Service of Application.
At the debugging time, to learn about system performance or retrieve an audit log, an administrator may send a request to the reporting API.
The response is <audit trail>, <metrics>, etc.