Backend interview: When should HTTP 226 IM Used carry a delta?

Prompt and scope

An API returns a large JSON document and the client stores the previous ETag. Explain when HTTP 226 IM Used is appropriate, which headers the client and server exchange, and how correctness is preserved when a delta cannot be applied. Cover negotiation, caching, and fallback; no specific diff algorithm is required.

What interviewer is testing

• Whether you know 226 represents a delta for GET, not an arbitrary incomplete success.
• Whether you can connect A-IM, IM, ETag, and optional Delta-Base into one exchange.
• Whether you identify base-version, cache-concurrency, algorithm-cost, and full-200 boundaries.
• Whether you will verify support in clients, intermediaries, and caches before deployment.

Clarifying questions

1. Can the client apply a negotiated instance-manipulation algorithm?
2. Is the document strongly identified by a stable ETag, and is delta generation worth its CPU cost?
3. Will a proxy rewrite or cache the response, and can it preserve delta semantics?
4. Can the client transparently fetch a full representation when its base is stale or invalid?

A 30-second answer

I would make 226 an optional negotiated optimization. The client sends A-IM and the base representation's If-None-Match. The server returns 226 only when it supports an algorithm and has that exact base, declaring the algorithm in IM, a new ETag, and Delta-Base when useful. The client verifies the base tag, applies the delta, and validates the resulting entity tag. A mismatch, poor cost-benefit, unsupported client, or failed merge falls back to a full 200. Caches must only reuse a delta when its base and response metadata match.

Step-by-step design

1. Negotiate delta capability

A-IM lists instance-manipulation algorithms accepted by the client; the server names its choice in IM. This differs from content-encoding compression: compression changes transfer coding, while a delta changes how the representation is produced. Without a mutually supported algorithm, use 200.

2. Bind the base to a version

The client uses If-None-Match to identify its local entity tag. The server must confirm that tag maps to the base representation, rather than guessing from a timestamp or client-provided version. The response carries a new ETag; Delta-Base can explicitly identify the base tag. The client validates the merged result against the new tag.

3. Make fallback safe

If the base is missing, the delta is larger than the full document, the algorithm times out, the merge fails validation, or an intermediary is unsafe, return 200. The client should discard the unusable base and resynchronize, so a bad delta cannot poison later updates. Apply size, CPU, and time budgets.

4. Treat cache keys and metrics as part of the protocol

Cache keys must include the URL, negotiation headers, and conditions that select the base; a delta valid for one ETag is not a generic response. Measure 226 hit rate, delta versus full bytes, merge failures, fallback ratio, and generation latency to prove that the optimization pays for its complexity.

Model high-quality answer

I would ship it as an optimization with an explicit fallback. The client advertises supported A-IM algorithms and sends If-None-Match for its base. The server checks that the base exists and that the algorithm is allowlisted, then compares delta size and generation cost. Only then does it return 226, declare the algorithm with IM, issue the result's new ETag, and optionally identify the base with Delta-Base. The client verifies the base tag, applies the delta, and validates the new entity tag before replacing its document. Any version mismatch, oversized delta, merge failure, or unsupported path returns 200. Caches vary by negotiation and base conditions, while telemetry records bytes saved, CPU, failures, and fallback. Delta support improves transfer efficiency without becoming a correctness prerequisite.

Common mistakes

• Treating 226 as 206, even though 206 answers a Range request.
• Sending only an informal version number instead of binding the exact base with ETag.
• Assuming every browser, proxy, and cache understands delta semantics.
• Skipping the comparison between delta size and full-document size.
• Continuing from an invalid base after merge failure instead of resynchronizing.
• Treating compression, JSON Patch, and RFC 3229 instance manipulation as the same protocol layer.

Follow-up questions and responses

How does 226 differ from 206 and 304?

206 returns byte ranges requested with Range; 304 says a conditional request needs no new representation; 226 returns a delta based on an existing representation. Their request conditions, client processing, and cache semantics differ.

What if the base ETag is stale?

Do not apply the delta blindly. Return a full 200 or have the client obtain the current base, discard the unusable local base, and rebuild its cache from a complete representation.

How do you prevent delta-cache poisoning?

Bind the URL, negotiated algorithm, base ETag, and response ETag; validate IM and Delta-Base; prevent intermediaries from reusing a delta for another base; and verify the merged entity's integrity.