Idempotency in HTTP Methods
Fast recall
Quick revision
Core answer
GET, HEAD, OPTIONS, TRACE, PUT, and DELETE are idempotent by method semantics; POST and PATCH have no general idempotency guarantee.Interview-ready guide
Interview answer
An HTTP method is idempotent when several identical requests have the same intended effect on the server as one request. It does not mean the responses must be identical or that the server performs no internal work. A server may log every attempt; the requested resource effect is what must not be applied again.
HTTP defines GET, HEAD, OPTIONS, and TRACE as safe and therefore idempotent. PUT and DELETE are also idempotent even though they request a state change. POST and PATCH have no general idempotency guarantee. For example, setting a status to paid can reach the same state twice, while adding ten credits repeats the change.
Suppose DELETE /orders/42 succeeds but the response is lost. A retry might return 404 Not Found because the order is already absent, yet the intended final state is still the same. Repeating the same PUT /settings/42 representation should likewise leave the same settings. Different responses do not by themselves make a method non-idempotent.
POST does not provide an idempotency guarantee, so retrying POST /payments blindly can create a duplicate payment. An API can add an idempotency-key contract: the same key and the same request identify one logical operation, while reusing the key with different content should be rejected. This is behavior supplied by the API, not by POST itself.
Idempotency in HTTP Methods
Direct Answer
Idempotency means that several identical requests have the same intended effect on the server as one request. GET, HEAD, OPTIONS, TRACE, PUT, and DELETE are idempotent by method semantics; POST and PATCH have no general idempotency guarantee.
Deep Dive & Architecture
A network can lose the response after the server commits the change. From the client, that looks the same as a request the server never received. Idempotent method semantics let the request be repeated without repeating the intended effect.
An API can define an idempotency key as its own contract for a non-idempotent operation. That contract must explain what counts as the same request, how long a key is remembered, what a completed retry receives, and what happens while the first request is still running. Those rules are application-defined; POST and RFC 9110 do not supply them. The implementation also has to stop two concurrent requests with the same key from both being treated as new.
Conditional requests solve a different problem. If-Match prevents applying a change to an unexpected version, while an application-defined idempotency key can identify a repeated logical operation.
Code Example
POST /payments HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 54
Idempotency-Key: 82c35d3e-8d70-44f9-aaf3-24ad14d8e615
{"orderId": "O-42", "amount": 1999, "currency": "INR"}
A retry uses the same key only for the same logical request. The API must define expiry, mismatch, in-progress, and failure behavior.
Check your understanding
Answer these without looking back at the article.
- Can an idempotent request return different responses?
- Why is PATCH not idempotent by specification?
- What race must an idempotency-key store prevent?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.