Cache Response Key

TIBCO API Exchange Gateway uses the cache response key to check if a cached response exists in the cache for an incoming request.

By default, the Core Engine constructs the value of the cache response key for REST/HTTP requests using the following parameters:

routingKey+requestURI(minus the API Key)+Accept-Header+Soap Action

where,

  • Routing Key: when the routing key is added to the cache response key, this ensures that for each incoming request, the cached response is only returned for a particular routing key.
  • requestURI: this is the URI that contains the path and query parameters. The API key is removed from the URI.
  • Accept-Header: The Accept HTTP request-header may be used to pass a content-type preference to the target service. For example, a service may support an Accept-Header of application/xml or application/json to preferentially return the response message in XML or JSON format. For the purpose of caching, the request with Accept-Header of application/xml or application/json are managed as two separate requests. The Accept-Header is added to the cache response key as an additional discriminator.

    For example, if a user requests the JSON data for a URI such as /Books/BookOperations/Title/Power , the cached response is only returned if the cache value has a JSON response for that URI in the cache.

  • Soap Action: specifies the SOAP Action header for a HTTP SOAP request used to construct the default cache response key.

For HTTP/REST and HTTP/SOAP requests, the Core Engine creates a default caching key using the above parameters..

Note: You can override the default cache response key using the custom XSLT specified in the parsing step of a facade operation request. See Overriding Cache Response Key and Parameters on how to create a cache response key using XSLT.