I wrote about Etags some days ago, stating that:
The Etag header is, generally, a string that represents our resource in the HTTP headers.
Well, although the definition is pretty simple and good, I should be more clear about etags.
Sending etags over the network is a way to reduce bandwidth and load on your service, implementing a part of the HTTP cache specificationl: but you should really generate clever etags.
If you need to talk with the DB to generate the tag, you’re basically making your server work just a bit lesser than doing everything wthout HTTP cache, because you only save in generating the response.
A cool way to save more would be to save the query used to retrieve the resource:
Since this is a key that uniquely identifies the resource, this header could be generated based on the query used to fetch the data and generate the resource.
But be aware of using only this strategy: if you update you resource, that etag will always send a 304 to your consumer.
That’s why the HTTP specification gives us the possibility to mix caching strategies, with validation and expiration.
Mixing them, you’ll be able to save bandwith and computational resources giving your consumer more consistent data.
P.S. Yes, the web is inconsistent. Get over it.