...

The policy owner can configure the cache time-to-live (TTL) per policy , and the cache key used to cache each request (with every key-value pair).

In the policy settings, you specify the cache key parameters that the HTTP requests map to and set the cache response time and refresh interval.

...

Both the HTTP Cache Response and HTTP Retry Policies fail to evaluate expressions. As a result, the When this policy should be applied field should not be set. Doing so can cause issues with the way the policy is applied.

Architecture

This policy offers a map to send responses. The cache must be enabled through feature flags on the Snaplex.

You can confirm the following cache key types for the clientEach Snaplex node has its own cache, so the cache for an incoming request might miss on each node until properly distributed and hydrated on each node.

By default, the following cache keys are used:

• Protocol

• Host 

• Path 

• HTTP Method

The policy supports using incorporating headers and query parameters as part of the cache key (not to access the cache keyskey). The key is hashed with a SHA1 algorithmheaders and query parameter values are used as part of the generated cache key to ensure unique cache entries as needed.

Usage Guidelines

• We limit each policy to have 100 entries in the cache per policy. Accordingly, the policy evicts the least used entry after 100.

• Expired caches cannot be accessed, and new entries overwrite any existing ones. The maximum quantity of bytes that an HTTP response caches in the default configuration is 85.83 MB of the payload.

Limitations

• Each response cache can only contain 85 MB. The policy always returns the response, but any data over the limit renders the payload incomplete without notice.

• A response cache is not effective to use for POST and PUT HTTP methods because these operations are meant to alter the state of data, and hence therefore should not be cached.

Settings

Example

The policy supports using headers and query parameters to access the cache generate keys:

• We can recommend that the header and query string keys can be configured for caching HTTP responses with unique key-value pairs. For example, in a REST GET endpoint that multiplies two integers:

GET
/gateway/proxy/multiply?intA=[valueA]&intB=[valueB]

• Configuring the policy to use

  header keys

  query strings intA and intB to cache policies for every key-value pair that has query strings with intA and intB.

For example, the following GET requests

...

each have a separate entry:

/gateway/proxy/multiply?intA=5&intB=5
/gateway/proxy/multiply?intA=2&intB=2
/gateway/proxy/multiply?intA=3&intB=1

• The following HTTP responses

  will be

  are cached so that the proxied server does not need to perform the calculation:

Response 1 
{
    "operation": "5 x 5", 
    "result": 25
}

Response 2 
{
    "operation": "2 x 2", 
    "result": 4
}

Response 3
{
    "operation": "3 x 1", 
    "result": 3
}

If int C x int D were existing parameters, they would not be cache, because they're not configured in the policy.

Best Practice

Do not use any headers and query string parameters like a timestamp as part of your cache key or it never results in a cache hit.

You can optionally strip those headers using the Request Transformer policy. Alternatively, avoid headers/query string parameters as part of the cache key as needed when a unique value is present per request.