Reject a stale status update rather than silently overwriting newer data. When the request includes an If-Match condition and its entity tag no longer matches the current representation, return 412 Precondition Failed and do not apply the update. Reserve 409 Conflict for a conflicting resource state that is not simply a failed request precondition.
Why stale status updates need protection
A stale update occurs when two clients read the same client record, then one changes it before the other submits an update based on its older view. If the API accepts the later update blindly, it can overwrite the first client’s work—a lost update. HTTP conditional requests are designed to prevent that outcome. RFC 9110, published June 2022, describes using conditions with state-changing methods to avoid lost updates.
As an Amazon Associate I earn from qualifying purchases.
Use ETag and If-Match for optimistic concurrency
Return an ETag with the client representation, and require the client to send that value in If-Match when it changes the status. The server compares the supplied validator with the current representation before performing the update. For If-Match, RFC 9110 requires strong entity-tag comparison; a weak ETag does not provide this protection against changes to representation data.
For example, a client might retrieve a record and receive an ETag, then submit its status change with an If-Match header containing that tag. The specific URI, representation format, and status values depend on the API; the key is that the update is conditional on the version the client actually read.
Choose 412 or 409 based on what failed
| Situation | Response and behavior | Specification basis |
|---|---|---|
The request has If-Match, but no current strong entity tag matches. |
Return 412 Precondition Failed; do not apply the update. | RFC 9110 requires the server not to perform the method when the condition is false. It permits a 2xx response only when the server can determine that the same requested state-changing operation already succeeded. |
A PATCH encounters a conflict and the request’s If-Match or If-Unmodified-Since condition failed. |
Return 412 Precondition Failed to identify the failed precondition. | RFC 5789, published March 2010, distinguishes failed preconditions from other conflicts. |
| A PATCH cannot be applied because its assumed resource structure or state conflicts, and the request supplied no precondition. | 409 Conflict can signal the conflict. | RFC 5789. |
| PATCH operations must be processed in order, but the server cannot queue concurrent updates. | 409 Conflict can indicate the concurrent-modification condition. | RFC 5789. |
In short, use 412 when a supplied precondition is false; use 409 when the resource state prevents the requested patch for another reason. RFC 5789 says 412 is most helpful when the client supplied a precondition and it failed.
Make validation and the write atomic
Checking the ETag and then writing in separate, unprotected steps can leave a gap for another update to land after validation but before the write. The API’s storage layer should make the version check and update atomic, so the server can honor the rule that it must evaluate the precondition before performing the method. The RFCs define HTTP behavior; they do not prescribe a particular database transaction or storage design.
Rank #2
Give clients a safe recovery path
- On 412, leave the resource unchanged. The response should say that the update was not applied because the representation changed.
- Retrieve the current representation. After a failed PATCH, RFC 5789 says the client can issue GET to inspect the resource’s state.
- Reconcile the intended status change. Compare the current state with the client’s intended change. How to merge changes or decide whether the transition remains valid is an application-specific policy, not defined by these RFCs.
- Retry conditionally. If the change is still appropriate, submit a new update using the current ETag in
If-Match.
Document the API’s error-body format and recovery workflow: neither is standardized by the cited RFCs. A bare update without a validator cannot establish that the client’s view was current. RFC 5789 recommends conditional requests when a patch format depends on a known base point.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Do not replay a transition against newer state by default
A failed precondition should not become an automatic status change against whatever state happens to be current. The narrow case for a 2xx response is when the server can determine that the same state-changing operation already succeeded. Treating other failed preconditions as success can be risky, particularly when transitions are not atomic or other writers do not cooperate.
Quick Recap
Rank #3
- Contains one (1) API 5-IN-1 TEST STRIPS Freshwater and Saltwater Aquarium Test Strips 25-Count Box
- Monitors levels of pH, nitrite, nitrate carbonate and general water hardness in freshwater and saltwater aquariums
- Dip test strips into aquarium water and check colors for fast and accurate results
- Helps prevent invisible water problems that can be harmful to fish and cause fish loss
- Use for weekly monitoring and when water or fish problems appear
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
