A conditional request asks an HTTP API to act only when a resource condition holds. It prevents stale updates and avoids downloading unchanged data. section 12.5.4 section 13.4.1
Use the condition that matches the operation:
- For updates, return an ETag when reading a resource, then send it in If-Match. Reject a stale version with 412 Precondition Failed; the consumer rereads the resource before retrying. section 12.5.4
- For cached reads, send the previous ETag in If-None-Match. Return 304 Not Modified without data when unchanged, or 200 OK with updated data and a new ETag when modified. section 13.4.5
- Alternatively, use Last-Modified with If-Unmodified-Since for updates, or a date-based conditional read as supported by HTTP. section 12.5.4 section 13.4.5
Banking application cache
A banking app caches account 123 for ten minutes, but the balance may become inaccurate during that interval. Before displaying the cached balance, it sends a conditional read with the cached ETag. An unchanged account produces 304 and preserves the cache; a changed account produces fresh data and a replacement ETag. section 13.4.1 section 13.4.5
Figure 12.5 By returning the resource data version in an Etag header on reading, we can condition updates with the If-Match header and ensure that data stays uncorrupted.
Trace the read-ETag, update-If-Match, and stale-version rejection flow that protects updates from reverting newer data. section 12.5.4
Figure 13.8 The If-None-Match header allows us to return data only if it has changed compared to the provided Etag value.
Trace how If-None-Match distinguishes an unchanged cached representation from a modified one. section 13.4.5
