Over the past week, I have been spending time refreshing my knowledge of HTTP caching. I knew what caching was, but only vaguely. Right now, I’m working on a project which involves implementing a caching layer, for performance and scalability. I am a visual learner, so I did a little experiment.
Things caches do. Go and read it. Done? Great, now we’re on the same track. HTTP ETag (Entity Tag) is one of the mechanisms for web cache validation. The whole idea behind using an ETag is to validate whether it’s a Cache Hit or a Cache Miss. An ETag allows for conditional requests.
So, imagine a client [you] requesting a “share count” from the Graph API. The count is X, an integer. The header response returns an ETag value which you can store, and cache the entire response. The next time the client hits the server, it can validate whether it’s cache is invalidated with relative ease.
If the ETag hash retained in the cache is the same as the ETag received from the second request to the server, you have a cache hit, and the server doesn’t return a full response since the content hasn’t changed, saving you things like bandwidth and time.
Therefore, checking whether the response stored in your cache is the same as the response from a subsequent request is only a matter of performing a conditional request by comparing the two ETag hashes. Here’s a diagram, and then we proceed to the experiment I was talking about.
Experiment with Graph API
Let’s send a cURL request to the following resource. The share count is “11”.
</p>
cho graph.facebook.com/?id="http://www.mrgeek.me/technology/social-media/study-finds-the-most-popular-social-networks-for-specific-categories/"
HTTP/1.1 200 OK
Facebook-API-Version: v1.0
ETag: "c87d9c0b32d7741d7893c6965956f2ca14e10238"
Content-Type: application/json; charset=UTF-8
Pragma: no-cache
Access-Control-Allow-Origin: *
X-FB-Rev: 1467028
Cache-Control: private, no-cache, no-store, must-revalidate
Expires: Sat, 01 Jan 2000 00:00:00 GMT
X-FB-Debug: EPIExa4/Pgt3bBUtFYW1Elu1wQtv6wXHMQzBtKtbz1Pdw4uu8HUf9NA8yt4wjNtzJB5Nc2r3ixXPr9PhOU9qiQ==
Date: Thu, 23 Oct 2014 23:47:22 GMT
Connection: keep-alive
Content-Length: 141
{"id":"http:\/\/www.mrgeek.me\/technology\/social-media\/study-finds-the-most-popular-social-networks-for-specific-categories\/","shares":11}
The ETag is c87d9c0b32d7741d7893c6965956f2ca14e10238. It is a hash of the response body.
Now, let’s go and like the article to make the share count to “12”.
We hit the cURL request again and response is as follows.
cho graph.facebook.com/?id="http://www.mrgeek.me/technology/social-media/study-ar-social-networks-for-specific-categories/"
HTTP/1.1 200 OK
Facebook-API-Version: v1.0
ETag: "5290ffca8be5817e2ee1ccd3ac9f65ccce4d9d19"
Content-Type: application/json; charset=UTF-8
Pragma: no-cache
Access-Control-Allow-Origin: *
X-FB-Rev: 1467028
Cache-Control: private, no-cache, no-store, must-revalidate
Expires: Sat, 01 Jan 2000 00:00:00 GMT
X-FB-Debug: oelkZ/J8KAcjbm7FPaZYvJ4uRgeDU7utfDfuplmR/CSUDIEAgnnZu4Fau4qGMddulu0m+xW54GNGK9PMit9iLw==
Date: Thu, 23 Oct 2014 23:50:00 GMT
Connection: keep-alive
Content-Length: 141
{"id":"http:\/\/www.mrgeek.me\/technology\/social-media\/study-finds-the-most-popular-social-networks-for-specific-categories\/","shares":12}
If you see, the ETag hash has changed to 5290ffca8be5817e2ee1ccd3ac9f65ccce4d9d19.
This means the contents of the response body have changed.
So ETags are useful because:
- They prevent you from hitting API rate limits.
- Since you don’t return the full response all the time, bandwidth is saved.
- Serving data from the cache is faster.
- You save loads of time in this entire process.
Make use of ETags where you can. Enjoy!
About Ali Gajani
Hi. I am Ali Gajani. I started Mr. Geek in early 2012 as a result of my growing enthusiasm and passion for technology. I love sharing my knowledge and helping out the community by creating useful, engaging and compelling content. If you want to write for Mr. Geek, just PM me on my Facebook profile.
