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.
So let's see what are the options we have.
Since dynamic data can be cached for a short time period, the best way is to use the max-age.
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.
Max-age
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.
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.
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.
Whenever client wants the same data, it can do the API call by adding received Etag to the "If-None-Match" header.
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.
Last-Modified: Fri, 18 Jan 2019 10:19:00 GMT
Modified-Since: Fri, 18 Jan 2019 10:19:00 GMT
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.
Comments
Post a Comment