How do ETag and If-None-Match reduce API response transfer, and what makes an ETag implementation correct?

In production I choose a validator source that is both correct and cheaper than regenerating the full response. A read-model revision, aggregate version, or precomputed content hash may let the endpoint decide early; hashing a large serialized payload after every query can save bytes while saving no origin work. Authorization runs before conditional evaluation so the validator cannot reveal protected-resource existence or change state. I use weak validators only where weak comparison is valid and do not reuse them casually for write preconditions such as If-Match, which uses strong comparison. The 304 response carries the ETag and cache metadata required to update the stored response, while omitting the representation body. I test matching, non-matching, wildcard, multiple-tag, content-negotiation, language, user-scope, serializer-change, and proxy-cache cases. Metrics compare conditional requests, 304 rate, bytes avoided, database and serialization work, and validator computation cost. If the data changes too frequently or each response is highly personalized, measurement may show that ETags add complexity without enough value.