Two clients open the same record, both edit it, and the second save silently overwrites the first. How would you use ETags to turn that lost update into something the client can see and handle?
Return a strong ETag on GET, require If-Match on writes, and reject a stale token with 412 Precondition Failed so a lost update becomes a visible error rather than silent data loss. What makes it correct is that the comparison and the write must be one atomic operation - an UPDATE guarded by the version in its WHERE clause - because a SELECT then UPDATE reintroduces the race.
Answer
Short answer
Give every representation a version token in an ETag header on GET, and require the client to echo it in If-Match on PUT, PATCH or DELETE. The server compares the token against the current state and rejects a stale one with 412 Precondition Failed. The lost update becomes an error the client can react to instead of data quietly disappearing.
Was this answer helpful?
Likely follow-ups
- A client omits If-Match entirely. What should the server do, and what does that choice cost you?
- Your ETag is a hash of the JSON response and a proxy re-serialises it. What breaks?
- How would this differ for PATCH compared with PUT? What about DELETE?
- When would you put a version field in the request body instead of using a header?
- The client gets a 412. Design the user experience from there.
Related questions
- How do you design the error contract for an API that other teams have to program against?hardAlso on api-design and http6 min
- Clients are asking for page 4,000 of your /orders collection. How is that endpoint paginated, and what would you change?mediumAlso on http and rest5 min
- Which status codes and method semantics do you insist on in a code review, how do the caching headers fit together, and is the API you just described REST?mediumAlso on http and rest6 min
- The same domain has to be exposed to a mobile app, a partner integration and internal service-to-service traffic. Where does GraphQL fit, where does gRPC, and where does neither?hardAlso on api-design7 min