Updated on 2024-05-24 GMT+08:00

Response Cache

You can configure a response cache policy to cache responses returned by the backend service (server) in APIG. When a client sends the same request, APIG does not need to send the request to the backend service but directly returns the cached response. This effectively reduces the backend load and API invoking latency.

When the response cache policy is used, backend responses are cached to APIG. However, APIG now does not support cache data encryption, which poses security risks to sensitive data in responses. Therefore, exercise caution when configuring the policy.

The following figure shows the principle of the response cache policy.

Usage Guidelines

  • You have understood the guidelines for policy creation and API binding.
  • The response cache policy supports only APIs that use the GET and HEAD methods.
  • Response bodies larger than 1 MB will not be cached.
  • The cache size for backend response is 128 MB.
  • APIG processes the cache according to the Cache-Control header in the backend response. If the backend does not return the Cache-Control header, the response is cached by default, and the ttl field configured in the policy is used as the cache expiration time.
  • By default, APIG does not process the Cache-Control header of the client. You can change this by configuring the client_cache_control in the policy.
  • Cache-Control extended cache instructions are not part of the core HTTP cache standard document and are not supported.
    Cache-control: immutable 
    Cache-control: stale-while-revalidate=<seconds> 
    Cache-control: stale-if-error=<seconds>
  • APIG can cache only the Content-Type, Content-Encoding, and Content-Language headers. If you want to cache more headers, add them to the Cached Backend Headers in the policy. However, the system response headers (such as x-apig-* and x-request-id) added by APIG cannot be added.

Configuration Parameters

Table 1 Configuration parameters

Parameter

Description

Cache Proxy Key

The configuration is used to distinguish different caches.

  • system_params: default gateway parameters. For details about the parameters, see default gateway parameters
  • parameters: request query parameters.
  • headers: request headers

HTTP Config

The HTTP Status Code and Cache duration determine whether to cache data and how long the cache will be retained.

If HTTP parameters are not configured, the default Status Code is 200. Range: 200–599. The default cache duration is 300. Range: 1–720,000.

Cache Proxy Modes

The gateway processes the cache through the Cache-Control request header in the client request. By default, the gateway rejects all client requests with the Cache-Control header.

  • all: All client requests with the Cache-Control header are allowed.
  • off: All client requests with the Cache-Control header are rejected.
  • apps: Clients whose app IDs (credential IDs) are in the datas list are allowed.

Cached Backend Headers

By default, only the Content-Type, Content-Encoding, and Content-Language headers can be cached. If you want to cache more headers, add them to the Cached Backend Headers in the policy. However, the system response headers (such as x-apig-* and x-request-id) added by APIG cannot be added.

Example Script

{
  "cache_key": {
    "system_params": [
      "$context.sourceIp",
      "$context.requestId"
    ],
    "parameters": [
      "demo_parameters"
    ],
    "headers": [
      "demo_header"
    ]
  },
  "cache_http_status_and_ttl": [
    {
      "http_status": [
        200
      ],
      "ttl": 300
    }
  ],
  "client_cache_control": {
    "mode": "apps",
    "datas": [
      "demo_app_id_1,demo_app_id_2"
    ]
  },
  "cacheable_headers": [
    "demo_cacheable_headers_1,demo_cacheable_headers_2"
  ]
}