Use PUT to replace a whole resource and PATCH for a partial update. With PUT, the body is the complete new version, so any field you omit should be reset to its default or null. With PATCH, the body carries only the fields to change.
PUT /users/123
{
"name": "John Doe",
"email": "john@example.com"
}
# Replaces entire user object
PATCH /users/123
{
"email": "newemail@example.com"
}
# Only updates email field
PUT is idempotent, so a client can safely retry it. PATCH isn't guaranteed to be, because a patch such as "append an item" changes the result each time it runs. PATCH also sends less data. A PUT built from a stale copy can overwrite a field someone else just changed, so pair it with an ETag and an If-Match check.
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
A method's promise about safety and idempotency decides when a retry is safe, when a cache is legal, and PUT versus POST.
For this question · chapter 2 of 3Watch the email value disappear from the record when a PUT body arrives with no email. Then watch a PATCH body with plan only. Name and email stay.
2/3PUT replaces, PATCH merges
PUT replaces, PATCH merges
We called PUT a replace and PATCH a change. That difference can make people lose data. The server holds one document at /users/123 with three fields filled in: name Ada, email ada@example.com, plan free. A client at the other end of the connection can write to those fields with either PUT or PATCH.
PUT replaces the record instead of editing the record. A PUT body with all three fields arrives over the network, so PUT clears every stored field, then writes all three fields again from the body. The record now reads name Ada, email ada@example.com, plan free, exactly as before. Here the replacement happens to match what was stored before.
Now a PUT body arrives with only name and plan. PUT replaces the whole stored record again, so the server clears all three fields and fills only two. Nothing arrives for email, so the record no longer has an email field. A field left out of a PUT body is a deletion, not a request to keep the old value.
The stored record again has all three fields filled: name, email and plan. The PATCH body carries only the plan field. The server changes plan from free to pro, but name and email stay as they were. PATCH sends the change, not the whole record, so the server merges that change into what is already stored.
The server receives the full PUT twice, then the same PATCH twice. The record holds the same values after each call: name Ada, email ada@example.com, plan pro. Setting plan to pro twice still leaves the plan at pro. Both calls are idempotent here, so a client that never got the reply can safely send either call again.
A fourth field, tags, starts as an empty list. PATCH comes in two common forms: JSON Merge Patch sends the fields to merge, and JSON Patch sends a list of operations. One add operation on /tags/- runs twice, so the first run writes vip and the second run appends a second vip. Append is not idempotent, because each run adds one more entry.
Use PUT when the client has every field, because PUT sends the whole record. Use PATCH when the client has only the change. Give each method on a route one meaning, so PUT and PATCH never do the same job. A PUT to an id that does not exist may create the record and return 201.
Chapter 2 · step 1 of 7
We called PUT a replace and PATCH a change. That difference can make people lose data. The server holds one document at /users/123 with three fields filled in: name Ada, email ada@example.com, plan free. A client at the other end of the connection can write to those fields with either PUT or PATCH.
Saved in this browser - sign in to keep your review list.
How should your speech become text?
Listening… your words appear above as you speak - tap Stop when you're done.
Recording · cr - tap Stop & transcribe when you're done.
Transcribing with AI…
Voice:
Keep going - a few more words and AI can grade it.
Interview lens
How interviewers actually use this question
Likely follow-ups
Is PATCH ever idempotent in practice, and how would you make a PATCH safe to retry?Setting a field to a value repeats safely, but append or increment ops don't. For those, name an If-Match precondition or an idempotency key.
What formats can a PATCH body use, and how do you clear a field with JSON Merge Patch?JSON Merge Patch sends a partial document where null removes the field. JSON Patch sends a list of ops like add, remove and replace.
Two clients edit the same user at once. How do you stop one from silently overwriting the other?Return an ETag on GET and require If-Match on PUT or PATCH. On a mismatch, answer 412 Precondition Failed and have the client refetch.
A PATCH tries to change a read-only field like id, or one field fails validation. What does the server do?Reject the whole patch with a clear 4xx error. Don't apply part of it or quietly ignore the field, because a patch applies atomically.
What you can say
PUT replaces the whole resource, and PATCH changes only the fields you send.
With PUT the body is the complete new version, so if I leave a field out, the server should reset it to its default or null.
With PATCH I send only what changes, say just a new email, and every other field stays as it was, so the request is smaller too.
PUT is idempotent, so a client can safely retry it after a timeout.
PATCH isn't guaranteed to be, because an operation like 'append an item' gives a different result each time it runs.
One catch with PUT is that a body built from a stale copy can wipe out someone else's change, so I'd pair it with an ETag and an If-Match check.
Weak answers to avoid
Treats PUT as a partial updateUnder PUT, fields left out of the body get reset. Say the PUT body is the full resource, and send a partial body only with PATCH.
Says PATCH is never idempotentIt isn't guaranteed to be, which is a different claim. Setting email to a value gives the same result every time, and appending an item doesn't. Give both cases.
Ignores concurrent writesA PUT built from a stale copy overwrites another client's change. Mention an ETag with If-Match, and a 412 when the ETag doesn't match.
Recites definitions but never says whenThe question asks when. Give a case, like PUT for a form that sends the whole object and PATCH for changing one field.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
