Apama 10.15.3 | Connecting Apama Applications to External Components | Standard Connectivity Plug-ins | The HTTP Server Transport Connectivity Plug-in | Handling requests to different paths with different chains
 
Handling requests to different paths with different chains
You can provide the HTTP server with multiple chain configurations specifying different mapping rules for different requests. These rules are differentiated based on the path of the HTTP request. To do this, provide more than one entry in the dynamicChains section of your YAML configuration file, each finishing with an instance of the HTTP server transport. To use this feature, you must provide a distinct matchPathPrefixes configuration option on each of the transports. This is a list of string prefixes which are handled by the given chain. Typically, one of the chains has a default entry of "" (the empty string) which handles all requests not handled by any other chain.
For example:
dynamicChains:
DefaultHTTPServerChain:
- apama.eventMap
mapping rules...
- HTTPServerTransport:
allowedMethods: [GET]
automaticResponses: false
matchPathPrefixes: ""
RESTHTTPServerChain:
- apama.eventMap
mapping rules...
- HTTPServerTransport:
allowedMethods: [GET]
automaticResponses: false
matchPathPrefixes: ["/rest", "/api"]
CRUDHTTPServerChain:
- apama.eventMap
mapping rules...
- HTTPServerTransport:
allowedMethods: [GET,PUT,DELETE,POST]
automaticResponses: false
matchPathPrefixes: ["/rest/objects"]
In the above example, requests to /rest/objects are handled by the CRUD chain. Requests to other places under /rest or /api are handled by the REST chain. Anything else is handled by the default chain. Each chain can provide different mapping rules for different formats of request, mapping to different EPL events and delivering to different channels.
The HTTP server lazily instantiates chains of each type for each incoming thread (if using the concurrentChains option), so they are not created until a matching request comes in on a given thread.
If there are two chains with overlapping prefixes, the prefix with the longest match is chosen. For example, if the first chain specifies /data and the second chain specifies /data/instances, then a request to /data/global uses the first chain, but a request to /data/instances/12345 uses the second chain.
Queueing behavior
You can configure each chain to deliver to separate channels. This potentially allows that if requests to one of the channels are backed up or blocked, requests to independent paths can still be processed. It also means that ordering is not guaranteed across different chains. Each chain has its own response channel, which is mapped into the chain using the @{httpServer.responseChannel} variable when it is created.
If you want to ensure that requests using one chain do not block requests using another chain, then you must do the following:
1. Ensure requests on each chain are delivered to a different channel, possibly by setting a different defaultChannel configuration property on each host plug-in.
2. Subscribe different contexts to each channel.
Logging and metrics
In order to distinguish the different chains in log message and Prometheus metrics, a label of {template=nameOfDynamicChain} is added to the name of the chain and any metrics in that chain.