POST asks the server to create a new resource and choose its identifier. PUT creates or updates the resource at an identifier the client provides. So POST /users creates a new user, while PUT /users/123 creates or updates the user with ID 123.
The other difference is what a repeat does. POST is not idempotent, because multiple calls create multiple resources. PUT is idempotent, because multiple identical calls have the same effect as one.
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 · chapters 1 and 3 of 3The difference between PUT and POST is one lamp on row three, the idempotency guarantee: PUT is idempotent, POST is not. Watch that lamp. The next chapter counts what that lamp costs when a reply is lost and the client retries.
1/3Verbs have a meaning and a code
Verbs have a meaning and a code
Every HTTP verb is a promise to the client about what a call does. A broken promise means a retry duplicates a charge, or a cache stores an answer that should never be cached. Each verb has a plain meaning: GET reads and POST creates. PUT replaces the whole resource, PATCH changes only the fields in the request, and DELETE removes.
Row two asks whether the call changes anything on the server. Only GET is safe, because GET changes nothing. The other four methods can write. A safe method is one you can call without changing anything, so a browser may prefetch a GET but not a POST.
The second question, in row three, is whether the method is idempotent. Idempotent means a repeated call leaves the server in the same state. GET, PUT and DELETE are idempotent, but POST is not. PATCH depends on what the patch body does, so no one can promise in advance that a PATCH is idempotent.
The fourth question is who sets the id. The server picks the id for POST, so the client cannot know the address before sending the request. The client sets the target for PUT, PATCH and DELETE, and GET reads an id the client already knows. The client already knows the target, so the client can repeat a PUT without checking whether the first one worked.
Row five is the expected success code, the other half of the contract. GET answers 200 and POST answers 201, because something new now exists. PUT answers 200 or 204, PATCH answers 200, and DELETE answers 204. A 204 means the work is done and there is nothing to send back.
Read the POST column top to bottom: it's not safe, not idempotent, and server picks an id. The bottom of the column is the status code 201. POST is the only verb with every guarantee switched off, so you have to protect POST yourself.
POST keeps adding, PUT stays
The server keeps a count of users, and right now that count is 0. That count will change here, and how it changes depends on the operation the client sends.
A POST request to /users reaches the server. The server picks the id itself, in this case 41, and the user count becomes 1. One request created one user, as expected. Now the server sends the reply back to the client.
The reply is lost halfway back across the network, so the client receives nothing. Now the client has two possible explanations. Either the reply was lost on the way back, or the request itself failed. In both cases the client receives nothing, so the client cannot tell them apart.
The client does not know what happened, so it sends the same request again. The server handles this second request and creates user 42, so the count of users rises to 2. The server treated the two as separate requests, because nothing in the second request marked it as a repeat. Both requests were valid POSTs.
One more retry creates user 43. The server now holds three users, and the caller wanted only one. Replace users with charges, and the same retries charge a customer three times. POST makes no promise against duplicates, so POST is not idempotent.
The client sends a PUT request to /users/123. The client chose that address itself, so the server only acts on the one record at that address. The network is no better than before. But the address now names one record instead of a collection, and that change alone makes the retry safe.
The reply is lost again, so the client retries two more times. Each retry writes the same record with the same body. The count stays at 1. The server did the work three times, but the state after three calls is the same as the state after one. Repeating the call changed nothing, so the call is idempotent.
A charge cannot be a PUT, because the client has no id to set. So the client sends POST /charges with an Idempotency-Key header, 9f2, and retries twice under the same key when the reply is lost. The server stored its first response under that key, so every repeat gets that same response and the charge count stays at 1. Stripe uses this mechanism and keeps each key for 24 hours.
Chapter 1 · step 1 of 6
Every HTTP verb is a promise to the client about what a call does. A broken promise means a retry duplicates a charge, or a cache stores an answer that should never be cached. Each verb has a plain meaning: GET reads and POST creates. PUT replaces the whole resource, PATCH changes only the fields in the request, and DELETE removes.
A method is a promise about two things. Does the call change state, and does calling again change anything more? That promise decides when a retry is safe, when a cache may keep the answer, and PUT versus POST. Pick the verb whose promise matches the work, and protect POST with a key that detects a repeat.
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
When would you use PATCH instead of PUT?PUT sends the full replacement, so a missing field gets dropped. PATCH sends only the change and is not guaranteed to be idempotent.
How would you make a POST that charges a card safe to retry?Name a client-generated idempotency key. The server stores the first result under that key and returns it on a repeat instead of charging twice.
Which status codes should PUT and POST return when they succeed?A POST that creates returns 201 with a Location header. PUT returns 201 when it creates and 200 or 204 when it replaces.
Two clients PUT different versions of /users/123 at the same time. What happens, and how do you prevent it?The last write wins and one update is lost. A strong answer uses an ETag with If-Match, so a stale write gets 412 Precondition Failed.
PUT is idempotent. Is it also safe, and what is the difference?Safe means the request changes nothing, like GET. PUT changes state, so it is idempotent but not safe. Repeating it leaves the same end state.
What you can say
POST asks the server to create something new. PUT puts a resource at a URL the client already knows.
With POST /users the server picks the new user's ID, so sending the same request twice creates two users. That's why POST is not idempotent.
With PUT /users/123 the client names the ID and sends the resource, and the server either creates it or replaces what's already there.
PUT is idempotent. Sending the same PUT ten times leaves the server in the same state as sending it once.
That matters for retries. A client can resend a PUT after a timeout without harm, but a resent POST can create a duplicate unless you add an idempotency key.
The trade-off is who owns the ID. PUT only works when the client knows the ID up front, so when the server should assign IDs I use POST and deal with duplicate retries separately.
Weak answers to avoid
Says POST creates and PUT updates, nothing morePUT can create too, at a URL the client picks. The question is testing idempotency and who assigns the ID, so talk about both.
Treats PUT as a partial updatePUT replaces the whole resource, so leaving out a field can wipe it. Partial changes belong in PATCH.
Can't say why idempotency mattersTie it to retries. A client can resend a PUT after a timeout safely, but a resent POST can create a duplicate order or a second charge.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
