The HTTP server is a transport for use in connectivity plug-ins which external services can connect to over HTTP/REST. It can handle HTTP requests and deliver the contained events to the correlator, which will return acknowledgment of the requests. In addition to this, it can serve static files. It also allows support for TLS alongside HTTP basic authentication.

For each service (host and port combination) that you want to be available for sending requests to, you must create a new instance of a connectivity manager and chain in your configuration file. To send a request, you send HTTPRequest events to that chain, where these events are correctly mapped as described in Mapping events between EPL and HTTP server requests. The acknowledgment response is sent back by the same chain instance.

Persistent connections to the server are supported for multiple requests. Details of the individual requests are configured through the events sent to the chain. The HTTP server supports HTTP version 1.1 and TLS version 1.2 and above.

The HTTP server is designed to listen for REST services and supports all GET, POST, PUT and DELETE operations which have been specified in the configuration file. Other than GET requests served by static files, all requests are treated identically.

The samples/connectivity_plugin/application/httpserver directory of your Apama installation includes a sample which demonstrate how to use the HTTP server connectivity plug-in to send and receive HTTP requests containing events into the correlator through various configurations. See the README.txt file included with the sample for complete instructions on how to run the sample application.

Swagger or OpenAPI 2.0 (OAS) is an open standard for defining REST APIs originally developed by the SmartBear company. The OAS, and the open source tools available, can be used to design, document, test and deploy the REST API for an application. The 3.0 specification (https://swagger.io/specification/) is being released at the time of writing, but it is backward compatible with the stable 2.0 specification (https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md) used to author our small sample.

The specification allows for the Swagger definition to be written in either YAML or JSON. We have chosen to deliver the Swagger definitions as JSON to disambiguate them from configuration files when they are deployed in the same directory. It is easy to convert between the two formats.

The specification allows the author to define the transport mechanism, data, requests, responses and to document the required REST API. There is an open source suite of tools that take this definition and allow it to be edited, documented and code to be generated (https://swagger.io/tools/). The editor is available as a web application or stand-alone and provides a representation of the definition that is interactive and informative. The editor allows the user to convert to and from JSON, generate server or client code, and generally manipulate the definition in intuitive and useful ways.

The transport returns a response to the client after HTTP parsing, but before processing by the correlator. We return a "202 Accepted" response to indicate that a failure may still occur later in processing the event. If there is a failure in parsing the HTTP part of the request, an error code is returned instead.

The various response codes that we currently support are described below.