Returning HTTP 304 Unmodified (without server-side caching)

Question

In HTTP 1.1, a web server could return a 304 Unmodified response when a If-None-Match header is included in the GET request.

For REST API, I've only seen implementations involving server-side caching of the entire response contents where the cache is typically invalidated on subsequent requests to modify the same resource (such as PUT, PATCH or DELETE).

As you may know, cache invalidation can be hard to do, especially when scaling out or when the underlying datasource can be changed through other means. Nevertheless, even without full server-side caching, surely omitting the response content alone might yield significant performance benefit.

Suppose that a web server intercepts every response to a GET request and merely adds an ETag header that specifies a hash value for the response content. Then, in subsequent GET requests, the If-None-Match header can be processed (again, after-the-fact) to ultimately have the response overridden with a 304 Unmodified response. Such implementation, stateless or not, would still be processing every GET request in the underlying datasource first.

Thus, my question is not about reducing the cost of hitting the underlying datasource (with caching), but reducing the network cost.

Is this a silly idea?

Could this be something useful to enable on (almost) every API?

Answer 1

I'm not sure about the "every API" comment. There are many situations where it can do more harm than good.

Consider an API which returns highly dynamic stock figures. The hit rate on ETag values could be very small, while the extra processing cost of calculating the hash of the response would be added to each and every call. Also, if your ETag hit rate is close to zero, then you'll be spending more bandwidth on ETag headers than saving on the rare cases when its value matches.

Obviously, there are many situations where it is useful. To determine when, I'd look at potential hit rates (i.e. how often do we get a match on ETag), ideally measuring them on a sample set in production. Then plug that into a formula that compares network savings vs. CPU impact. Cellular is indeed one case in point where bandwidth/latency considerations usually trump processing horsepower.

Maybe you could share your use cases, and APIs you have in mind. This would help with giving more specific advice.

Answer 2

If many of your clients are mobile apps and usually connect via cellular, and you have enough server horsepower, this seems reasonable to me.