REST API Caching

REST APIs being exposed over HTTP mainly, there is a great advantage for APIs through HTTP Caching.

Why caching is important for REST APIs? 

  • Reduced server load,
  • Low response time
  • Save bandwidth

The biggest gain through caching for REST APIs is reduced server load, because the clients can store a cached response for sometime in their local store and access it without hitting the server. So it will result in a low response time to the client making things faster for them.

Further, using E-tags (Entity tags), clients have the ability to check with the server whether the response has updated or not. The response body is sent to the client only if the response has changed from what client has cached. Otherwise a 304 Not-Modified response is sent without a response body. 

We'll discuss about ETags more later in this post.

What to cache? 

In your REST API, there can be data that doesn't change more frequently and also data that changes frequently. We can define those data types as near static data and dynamic data. At a glance one might think, it is pointless to cache dynamic data. However, it isn't the case. Supporting HTTP caching on dynamic data would be beneficial specially for a system with high traffic. When the content are cached even for a short time, it reduces the server load significantly.

On the other hand, static content can be cached for a long time period. Then a mechanism can be provided for client to check with the sever whether the response has been changed or not.

How to support caching?

There are number of options in terms of setting HTTP Caching related headings to support caching. We have to select the suitable method based on the requirement.

So let's see what are the options we have.


This is a directive supported in Cache-Control header. It says the maximum time duration which the data can be used from the cache. The API response should include this in the response header. So the client can use the cached response for that period of time and after that send a request to the server.
Since dynamic data can be cached for a short time period, the best way is to use the max-age.

Cache-Control: max-age=3600

Last-Modified and Modified-Since

The Last-Modified header says the date-time the response was last updated. The server can add this to the API response.

Last-Modified: Fri, 18 Jan 2019 10:19:00 GMT

Then the clients can store the response in the local cache and when they need the same data again, they have to send the API request by including  "Modified-Since" with the date-time they received in the first response.

Modified-Since: Fri, 18 Jan 2019 10:19:00 GMT

Now the server should validate whether the particular data was modified since then and if not send a 304-Not Modified response with an empty body. So the client can use the cached response from their local store.  If the data has been modified since, the server has to the send the response again.

This method is suitable for caching both near static and dynamic data. However, it is required to know that since this approach is time centered, there is a chance that client and servers has a time difference more than the expected cache time of a particular data. In that case this is approach is not suitable.

Etag and If-None-Match

This is very similar to the above flow of how caching works, except that this depends on the data itself, but not time. Etag is a unique value generated from the response data. The server adds that to the response, so that clients and store that response.

Etag: 7890854718304728402gd

Whenever client wants the same data, it can do the API call by adding received Etag to the "If-None-Match" header.

If-None-Match: 7890854718304728402gd

Now the server has to generate the Etag for the requested data and see whether what client has sent matches to that or not. If it doesn't match, that means the data has been changed and response should be sent again with the new Etag. If it does, server can just send a 304-Not Modified response.

Etags is suitable when using a time related solution can not be used.

So this is some basic information on how to support response caching in REST APIs over HTTP. Hope this helps. 


Popular posts from this blog

PHP-SOAP web service with out a WSDL

Boomi Mapping - Removing special chars from an input

How to add Maven dependency from a relative path referencing a local jar