Some of our most used API’s return data that doesn’t change very often. To reduce the number of calls to the backend and improve the latency of those API’s we use caching.

Caching in IBM API Connect can be done on invoke-policies that make a call to a backend service (http/https). The result of the API itself cannot be cached, only the response of the invoke is cached.

For this reason, the way we handle caching in IBM API Connect is by adding an extra API layer that does the caching between the API that needs to be cached and the consumer. Often this extra layer already exists (for example for managing security or client-specific mappings). For clarity I will refer to the original API as the base API and to the API in the extra consumer-specific layer as the proxy-API.

What we will do to implement caching is setting cache control headers in every response of the base API service and implement a caching strategy on the level of the API-proxies, that are unique for every consumer. This also makes sense, since not every consumer wants to use caching. IBM API Connect supports the Cache-Control response headers as defined in RFC7234 (https://tools.ietf.org/html/rfc7234).

There are some restrictions to the use of the cache. The underlying Datapower runtime only supports a shared cache. This means that API’s that require authentication (Authorization header) cannot be cached.

Base API

In the base API we will set a cache-control response header. The value will contain the time to live for the specific cache in seconds. This TTL is the maximum lifetime that the response should be cached by its clients.

Example below for a cache with a lifetime of 24hours

Cache-Control: public, max-age=86400

API Proxy

Cache response parameter

Controlling caching on invoke/proxy policy in API Manager is done with the cache response parameter. There are 3 possible values:

  • Protocol: This means that the policy will look at the Cache-Control response headers as defined in RFC7234 (https://tools.ietf.org/html/rfc7234). If the response indicates that caching is possible, the gateway responds to all waiting requests with the cached resource. If the response indicates that caching is not possible, the gateway sends all waiting requests to the target URL.
  • No cache: Responses from the target URL are not cached on the gateway regardless of any caching headers returned.
  • Time to live: This option is similar to the Protocol option except it allows you to specify the amount of time in seconds that you want the successful response from the invoke or proxy to remain in the cache. This does not overwrite the max-age value returned from the base API, so only use this option if you want to make the time to live shorter than what the base API returns.

We will use the 1st and 3rd option in case we want to implement caching. If we reuse the time to live from the underlying API’s response, we go for the first option.

In case we want to have a shorter lifetime for the cache, we can use the time to live option. We should never define a longer lifetime for the cache than the value defined in the response headers of the base API.

Other possible optional cache-options on the invoke

  • Cache key: Use this if you want to use a unique identifier for the call you want to cache. If not set, the URI is used as caching key.
  • Cache putpost response: Set this to ‘true’ if you also want to cache PUT/POST responses. By default this is set to ‘false’.

Datapower

You can check if the cache is working by logging into the Datapower domain of the API proxy and going to the ‘Document Status’ page. This page lists all cached documents, including the cached pages for IBM API Connect. (the other pages can be ignored they are part of the internal working of APIC)

Example:

Author: Tim Rombouts