How do If-Match and ETag help avoid overwriting a newer resource version?

That is a lost update: your edit is based on an older version than the one currently stored. An ETag identifies a particular version of a resource. You can keep the ETag returned when you read the resource and send it back in If-Match with your update. The server can then check whether your version is still current before applying the change. [S1]

Without that condition, an update based on an old copy may replace newer content, depending on how the server handles updates. With the condition, a mismatch can make the server reject the update with 412 Precondition Failed instead of applying it. [S1]

Assume, for illustration, that a read returned a resource body and the strong ETag "v7". The quotation marks are part of the example tag. You might send:

PUT /records/42
If-Match: "v7"
Content-Type: application/json

{"name":"Updated name"}

If-Match: "v7" means the update is conditional on the current resource matching that tag. If it does, the server may apply the update. If the resource has changed since your read, the tag no longer matches and the server can respond with 412 Precondition Failed rather than apply this update. [S2]

The server defines how it generates ETags; the format is not a version-number scheme you should assume or construct yourself. [S1] Treat the tag as an opaque value: retain the one received for that representation and send it back as the condition.

Do not silently resend the same update with the old tag: the condition is still based on the stale version. Fetch the latest resource and its ETag, compare the current content with the user’s intended changes, and reconcile them. If the changes can be combined, prepare an update based on the latest version and send it with that latest ETag. If they conflict, show the relevant differences or ask the user how to proceed. This is an application workflow, not something the status alone resolves.

For If-Match, comparison is strong, so a weak ETag will not match. [S1][S2] If the server supplies a weak tag, do not assume it can protect this update. Check the API’s documentation or ask its maintainer what conditional-update mechanism it supports. The cited guidance explains ETags and If-Match; it does not establish how a particular API implements updates, what its response body contains, or whether it supports another concurrency mechanism.

Use this sequence as a starting point; adapt it to the API’s documented request and response format:

1. Read the resource and retain its ETag exactly as returned.
2. Prepare the edit from that representation.
3. Send the update with If-Match set to the retained tag.
4. If the update succeeds, use the resulting resource and tag according to the API’s documented behavior.
5. If you receive 412, fetch the latest representation and tag; reconcile rather than blindly replaying the stale update.

Worked sequence: your client reads resource version "v7". Another editor changes it, so the current version no longer matches "v7". Your PUT with If-Match: "v7" is rejected with 412. You read the latest version, review whether your intended edit still makes sense, and submit a newly prepared update with the latest ETag. The example assumes the server supports this conditional-update behavior; the sources do not establish that every server does. [S1][S2]