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 services can be accessed via the following Service APIs:
8.1 Service Access
The full API definition of all available services is the set of all available OpenAPI descriptions.
One can take any of the available OpenAPI descriptions and call service according to that description.
This call must be forwarded to IM local Security Server and path part of the called URL must begin with the address of service in the form /r1/{instanceId}/{memberClass}/{member}/{application}/{service}/ followed by the service path with possible query parameters. The address of the service may be already listed in the OpenAPI description or must be added to the path if not provided by OpenAPI.
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.3.4 Event Type API
8.4 Logging Services
To get info from system log, an administrator may send a request to the logging API.
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