8 Service APIs
This section provides a reference for APIs that should be implemented by this Building Block.
The GovStack non-functional requirements document 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 this GitHub repository.
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 Swagger variant is available.
The services can be accessed via the following Service APIs:
8.1 Service Access
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.
8.2 Directory Services
8.2.1 Member Discovery
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.
8.2.2 Service Discovery
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.
8.3 Pub/Sub Service
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.
8.3.1 Subscriber API
8.3.2 PULL delivery mode API
8.3.3 Publisher API
8.4 Logging Services
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.
8.5 Monitoring Services
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.
8.6 Management API
8.6.1 Configuration Management
8.6.2 Management of Access Rights
Last updated