An ETag (entity tag) is a string the server sends with a response that uniquely identifies the resource version. When the client revisits, it sends If-None-Match: "etag-value"; if the server's current ETag matches, it returns 304 Not Modified with no body. The client uses its cache. ETags are also used for optimistic concurrency: If-Match on a PUT makes the update conditional on the resource not having changed since the client read it.
Servers compute ETags from resource content (often a hash of the bytes, or a generation number for database-backed resources). Strong ETags promise byte-identical content; weak ETags (prefixed W/) promise semantic equivalence but possibly different bytes. Most caches and clients accept both.
Generation strategies: hash the body (cryptographically simple, expensive for large bodies), use a database row version, or combine timestamp + size for static files. The cheapest correct ETag often beats a more sophisticated one.
ETags are the foundation of HTTP cache validation. A well-cached site can serve millions of requests with most responses being 304s, dramatically reducing bandwidth and origin load. ETags also enable lost-update protection in REST APIs.
TerminalFeed's data API endpoints use ETags where applicable. The 304 Not Modified status code page covers the conditional-request mechanism in detail.