Idempotency: PUT vs POST in REST

WHAT THIS TESTS This tests whether you understand idempotency precisely and can connect it to correct HTTP verb selection and retry safety.

A GOOD ANSWER COVERS An operation is idempotent if performing it multiple times has the same effect on server state as performing it once. PUT is idempotent: it replaces the resource at a specific, client-known URL, so sending the same PUT ten times leaves the resource in the identical final state. POST is not idempotent: each POST to a collection typically creates a new resource, so repeating it creates duplicates. Idempotency is distinct from safety; safe methods like GET do not modify state at all, whereas idempotent methods may modify state but converge to the same result on repeats. This matters for retries: a client or proxy can safely retry an idempotent request after a network failure without fear of duplicate side effects.

COMMON WRONG ANSWERS Saying POST is idempotent. Conflating idempotency with safety or with caching. Thinking PUT can only create, never update. Assuming idempotency means the response is byte-for-byte identical (it is about server state, not the response body).

LIKELY FOLLOW-UPS Is DELETE idempotent? How do idempotency keys make POST safe to retry? When would PATCH not be idempotent? Why does this matter for at-least-once delivery?

ONE CONCRETE EXAMPLE Updating a user's full profile at a known id fits PUT: PUT /users/42 with the complete new representation overwrites that user; retrying the request after a timeout is safe because the end state is identical. By contrast POST /users creates a new user each time, so a retried POST after a dropped response can create a duplicate, which is exactly why PUT is preferred when the client controls the target URL and wants a deterministic, retry-safe update.