Junior · Explain · Conditional GET and representation validators

Why can If-None-Match match a weak tag for GET, and what must a version-backed validator actually track?

Think through your answer before opening the explanation.

Production engineering

Reveal answer and reasoning

A validator relates a selected representation to a conditional request. In this fixture the document's monotonic version backs a quoted ETag, and the returned representation changes with that version. If-None-Match on GET uses the read precondition's weak comparison, so a matching weak tag can avoid transferring the body. The real endpoint uses typed framework headers and returns304 without a body when appropriate.

The companion handles only already specified classroom strings. It is not an HTTP parser, cache implementation or claim that arbitrary JSON, compression and user-specific variants all share the same representation identity.

A version-backed strong validator is meaningful only when it tracks every change relevant to the selected representation. Adding an uncontrolled timestamp or a user-specific field without changing the validator would undermine that claim. Conversely, returning304 does not mean the client received a new full body; it tells a correctly participating client how to use its existing representation under the precondition.

Do not reuse the known-string helper as a general header parser or apply weak-read matching to If-Match writes. Caching policy, content negotiation, authorization and validator comparison answer separate questions even when they appear on one HTTP response. The fixture always has an existing document; wildcard behavior for a missing selected representation would need another resource case rather than copying this304 expectation.

What a strong answer covers

  • The known-string helper prints True,True,False and is not a general header parser.
  • Actual matching read conditions return304 with no body; a nonmatch returns200.
  • Validator identity, cache-sharing policy and authorization are separate contracts.

Common pitfall

Treating a weak read match as write permission or an ETag as a complete cache and authorization policy.

Follow-up questions

  1. What happens when a serialized field changes without advancing the validator?
  2. How would negotiated or user-specific representations affect validator ownership?

Self-review

Choose what to revisit. These marks are your own assessment and are separate from lesson completion.

Primary references

Open lesson and code ↗

← All interview questions