Conditional Requests: ETags, 304 and 412

A conditional request is a plain request plus a claim about state: "I have the version tagged W/"v14" — proceed only as appropriate." The server compares the claim against reality and either does the work or returns a tiny answer: 304 Not Modified for reads ("your copy is current"), 412 Precondition Failed for writes ("the resource moved; your claim is stale"). Both superpowers hang off the same primitive: the validator, usually an ETag — an opaque token the server mints per representation — or the cruder Last-Modified timestamp (one-second granularity, ambiguous under rapid writes; use it as a fallback, not the primary).

The design decision hiding inside "just add ETags" is *what the tag tracks*. A strong ETag promises byte-identity; a weak one (W/"…") promises semantic equivalence — the useful promise for JSON APIs, where key order or a bumped retrieved_at timestamp should not invalidate every client's cache. Deriving the tag from a version counter or updated_at that changes exactly when the domain data changes gives you the semantics cheaply; hashing the serialized response gives byte-precision at CPU cost and breaks the moment serialization becomes nondeterministic. Whatever the recipe, it is a *contract*: if the tag changes when nothing meaningful changed, revalidation is worthless churn; if it fails to change on a real edit, caches serve stale data and preconditions fail to fence — the worst failure in this lesson, and a silent one.

The read side is a straight bandwidth trade. A dashboard polling a 180KB resource every 10 seconds pulls ~1.5GB/day/client unconditionally; with If-None-Match, unchanged polls cost a ~200-byte 304 — a 900× reduction on every poll where nothing moved, which for most dashboards is nearly all of them. The server still pays to *know* the answer (fetch or track the current version), so 304s save transfer and client parse time more than server CPU — unless the validator check is cheap (a version column read) while rendering is expensive, in which case the server wins big too.

Two honesty notes. First, conditional reads complement, not replace, freshness caching: max-age (see Caching as a Contract Clause) eliminates the request entirely for its window; revalidation makes the *next* request cheap. The strongest pattern is both — cache for 30s, then revalidate. Second, the mechanism only pays where responses are re-requested unchanged: a feed that changes every poll gets zero 304s and pure overhead; a per-user config read on every app launch is the perfect customer. Measure the 304 rate before and after; it is the mechanism's ROI in one number.

The write side reuses the validator as a concurrency fence. The lost-update race — two clients read v14, both edit, second write silently destroys the first (anatomy in The Lost Update, Step by Step) — is closed by making the claim mandatory: If-Match: W/"v14" on the write; the server compares and returns 412 Precondition Failed if the resource has moved. The loser refetches, sees the winner's change, and reconciles — merge, prompt the user, or retry the edit against the new version. Who reconciles, and how, is the real design decision; the status code just guarantees there *is* a loser instead of a silent casualty (strategy and alternatives in Optimistic Concurrency: Versions and If-Match).

Contract details that decide whether the fence holds: writes without If-Match on protected resources should be *rejected* (428 Precondition Required) rather than quietly accepted, or the fence only guards the clients that least need it. Every write response must return the fresh ETag, or clients are forced into an extra GET per edit cycle. And the 412 body should carry the current version — possibly the current representation — so reconciliation costs zero extra round trips. PUT and PATCH both take the fence identically (PUT vs PATCH covers what each method itself promises); the fence answers the question neither method can: "is my mental model of this resource still true?"