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?