You are designing a JSON REST API and want conditional GET support so repeat readers can be answered with HTTP 304 Not Modified. What does the server have to implement for those 304s to actually be cheap, where do the savings land, and when would you decide the feature is not worth adding at all?

## The design question, not the wire question A conditional GET lets a server answer "your copy is still current" instead of resending the representation. The header-level handshake that produces the 304 belongs to HTTP caching; the API-design question is different and much more consequential: **how much work does your server do before it can decide?** If the answer is "all of it", you have bought a bandwidth optimisation and nothing else — which is sometimes fine, but you should know that is what you bought. ## Three ways to source the validator **1. Regenerate and compare.** Run the query, build the DTO, serialize it, hash the bytes, compare with what the client sent. Correct and trivial to bolt on (most frameworks offer it as a filter), but the origin has done 100% of its normal work. You save egress and client-side parsing. Nothing else. **2. Hash stored at write time.** Every write recomputes and persists the content hash of the canonical representation. Reads fetch one small column. Cheap on read, but the hash is now tied to a particular rendering, so it must be recomputed whenever the serializer changes, and it is awkward when the representation depends on request parameters. **3. Version or state token.** Each row (or aggregate) carries a monotonically increasing version — an optimistic-locking counter, a sequence-backed change id, or the storage engine's own row version. The validator is derived from it, is readable in one indexed lookup, and is naturally correct across any rendering. This is the design that makes 304s cheap at origin. Whatever the source, the handler must **check the validator before assembling the payload**. A version column read after you have already loaded the aggregate saves nothing but bytes. ## Where the savings land Saved: response bytes on the wire (matters most on metered, mobile, or intercontinental links); client-side JSON parsing, object allocation and re-render; and, with strategies 2 and 3 plus an early short-circuit, origin database and CPU time. Not saved: the TCP/TLS connection, DNS and routing, authentication and authorization, rate-limit accounting, request logging — and above all the round trip. Conditional GET does not make a chatty API fast; it makes a fat API thin. If latency is your problem, a freshness lifetime that removes the request entirely, or a coarser endpoint that returns more per call, is the actual answer. ## Making the validator correct The validator must be a function of everything that can change the bytes you would send: - the resource's own version; - **embedded children** — an order that inlines its line items must change its tag when a line item changes, so you need an aggregate version or a max over the graph; - **request-shaped payloads** — `fields=`, `include=`, `expand=`, sort and page parameters all produce different bytes at what may be the same URL path; - **negotiated variants** — language, media type, API version header; pair these with `Vary`; - **the caller's authorization view** — if two callers with different scopes get different JSON, one validator per URL is a data leak waiting for a shared cache; - **your own serializer/schema version** — fold a build or schema id in, so a deploy that renames a field invalidates every stored copy instead of leaving clients on last week's shape. Weak versus strong matters here as a promise you can keep. A strong validator asserts byte-for-byte identity; a weak one (`W/` prefix) asserts semantic equivalence. JSON APIs rarely control their bytes — compression, key ordering, float formatting — so weak is usually the honest label. Strong tags are needed for byte-range requests, which most JSON APIs never serve. ## Collections are the hard case A single resource has an obvious version. A collection page must reflect inserts, updates, deletes and reordering: `max(updated_at)` silently misses deletes. Practical options are a tenant- or table-level change counter bumped on every write (cheap to read, over-invalidates, and that is usually acceptable), or a monotonic "last change id" per tenant. Often the better API answer is to skip conditional GET on collections entirely and offer a delta/since-cursor endpoint, which returns only what changed and beats an all-or-nothing 304. ## CDN interplay If a CDN or reverse proxy fronts the API, the economics shift. The edge holds the copy and revalidates with the origin, so one cheap origin revalidation can serve many clients and you save origin egress as well as client egress. But that only works for shareable responses: per-user payloads must be marked private, the edge drops out, and your 304 saves one client's bytes again. Conversely, for genuinely public content, a plain freshness lifetime (optionally with stale-while-revalidate) removes the request altogether and outperforms any conditional GET — reach for 304s when correctness requires the client to confirm each time. ## When to skip it Skip when payloads are a few KB after compression (the 304's own headers are not much smaller), when the resource changes on nearly every read so the validator almost never matches, when computing the validator costs as much as the answer, and for internal service-to-service calls on a fat network where the round trip dominates. Adding ETags "because REST" buys a new class of staleness bug — a validator that fails to change — for no measurable win.