This chapter provides a detailed specification for the HTTP Transport and describes how clients use the transport to communicate with HIS. It contains these sections:
· Protocol Requirements & Limitations
· Direct Client Protocol Services
...
To use the direct client protocol over HTTP, a client must first initiate a new session with HIS using the Session Management service. Once a client has an active session, it can send requests and poll for responses and events. When a client is finished using the direct protocol, it should explicitly close its session. Sessions will automatically be removed if no request is received or no event polling occurs for greater than the session timeout, which is configurable. The Session Management service can be accessed with the following URL:
http://[server_name]:[server_port]/sessions
The following diagram illustrates the typically lifecycle of clients using the Direct Client Protocol over HTTP:
...
Once a client has an active session, it can begin sending Direct Protocol requests to HIS. To send a request, the client POSTs the request JSON to the Request Processor service and provides its identifier. The service can be accessed using the following URL:
http://[server_name]:[server_port]/direct/processRequest?clientId=[client_id]
The contents of the POSTed JSON are delivered as-is to the direct protocol handler for processing. The server responds with an HTTP 200 OK status code if the message is accepted for processing. It is important to note that the HTTP response does not indicate that the request was completed successfully, but only indicates that the request was accepted and queued for processing. Any response message for the request must be retrieved via the Message Polling service.
...
As the client interacts with HIS, it needs to retrieve the responses to its requests and any events that might arise. The client must poll for new messages using the Message Polling service. The service can be accessed using the following URL:
http://[server_name]:[server_port]/direct/getMessages?clientId=[client_id]
To reduce the latency in receiving messages and the overall network traffic, the Message Polling service employs long polling. The service will not provide a response to the getMessages request until at least one message is available or some timeout has passed. Any messages that become available between client requests will be queued and delivered during the next polling cycle. Received messages should be processed in the background, allowing the client to immediately start the next polling cycle.
...