Downstream caching

Downstream caching refers to the caching instructions associated with objects sent with responses to clients, such as browsers, mobile devices, or client proxies.

Note: This section explains the concept of downstream caching. For specific steps to configure downstream caching in API Gateway, see Configure caching.

In the Downstream cacheability section, you can decouple caching in the last mile from the browser caching settings. When doing so, you can choose whether to use the headers sent by your origin to control caching behavior or have the headers and their values controlled by edge servers.

By default, Akamai calculates the downstream caching lifetime based on your API-level caching instructions or your origin caching headers. If your API-level caching behavior is set to No store or Bypass cache, edge servers attempt to prohibit downstream caching by sending so-called cache-busting headers to clients. Cache-busting headers include Expires:<current_time>, Cache-Control: max-age=0, Cache-Control: no-store, and Pragma: no-cache.

You can implement one of the following downstream caching options:

Allow caching
Allow downstream caching, choose the caching lifetime policy and the headers that edge servers should send to clients. You can configure the cache lifetime policy in relation to the settings in your origin headers or edge servers’ time-to-live (TTL), specify a fixed maximum age value, or calculate the lifetime based on the origin Cache-Control header. For more details on these options, see Cache lifetime options. You can also apply the Mark as private directive that prevents sensitive data from being stored in shared caches.
Allow caching, require revalidation (no-cache)
Allow downstream caching with a mandatory origin revalidation before a cached copy reaches the request sender. While the standard Allow caching option only revalidates with the origin once an object’s TTL has expired, this option forces the browser to send an If-Modified-Since GET request every time it requests an object. If the object has changed since the last time it was cached, the origin server sends the new version; otherwise, the origin sends an HTTP 304 Not Modified response. You can also apply the Mark as private directive that prevents sensitive data from being stored in shared caches.
Don’t allow caching (bust)
Send cache-busting headers downstream to prohibit downstream caching.
Pass cacheability headers from origin
Apply your origin’s Cache-Control and/or Expires header settings to downstream clients. Your origin cache headers will be passed to clients without any alteration.
Don’t send headers, apply browser defaults
Don't send any caching headers and let client browsers cache content according to their default settings. The default settings may vary from browser to browser.
Note: To learn more about downstream caching, see the “Downstream Caching” section in the Edge Server Configuration Guide. You can find this guide under Support in Control Center. Note that this guide focuses more on websites than APIs, but the core explanations of caching behaviors apply to both environments.