How API Requests Are Cached
How API Requests are Cached.
What is cache? Caching means storing responses in cache memory. These stored responses can be reused in subsequent requests as opposed to requesting them from the server again.
What is the purpose of cache? Caching avoids unnecessary network requests by retrieving resources from the cache instead of via repeated server requests. Doing this lowers latency and improves API performance.
How does caching work? Cache is controlled by the HTTP Cache-Control header, which has several directives that dictate the cache conditions. For example, the 'max-age' directive defines how long a resource will remain cached in a browser in seconds. Once 'max-age' has expired, the cache is cleared, and the resource must be requested from the server when it is next needed.
How API calls are cached: the client makes a GET request. The resource requested does not exist within the cache, so it goes to the server. The server delivers the resource with a 'Cache-Control: max-age: 1800' header in its response. The resource is then stored in the browser's cache until 1800 seconds have passed. Until then, subsequent requests for the resource are only retrieved from the cache.
Here are some additional Cache-Control directives to be aware of. 'public' indicates a resource can be stored in a shared cache, such as a CDN cache, even if it requires HTTP authentication to access.
'private' indicates the resource is intended for a single user only and, therefore, cannot be stored in public caches. Instead, it is only stored privately, e.g., in the user's browser.
'must-revalidate' prevents the use of stale resources. Stale resources must be invalidated against the server before being delivered to the client.
'no-store' prevents all browsers and intermediate/shared caches from storing the resources (resource is not cacheable).
'no-cache' allows caching but forces the browser to revalidate the resource against the server on each request.
Here's an example of a typical Cache-Control workflow.