What is idempotency and which HTTP methods are idempotent?
Understand idempotency in REST APIs, which HTTP methods are idempotent (GET, PUT, DELETE), why POST is not, and how idempotency keys enable safe retries.
Expected Interview Answer
Idempotency means that making the same request multiple times has the same effect on the server as making it once. GET, HEAD, OPTIONS, TRACE, PUT, and DELETE are idempotent; POST and (in general) PATCH are not.
Idempotency is about the resulting server state, not the response body — a second DELETE may return 404 while the state (resource gone) is unchanged. It matters because networks are unreliable: clients can safely retry idempotent requests after a timeout without risking duplicate side effects. POST is not idempotent because it typically creates a new resource each time, and PATCH is idempotent only when its body describes absolute values rather than relative changes.
- Enables safe automatic retries on network failures
- Prevents duplicate resource creation and double charges
- Simplifies client and proxy caching logic
- Makes distributed systems more fault tolerant
- Clarifies which methods need idempotency keys
AI Mentor Explanation
Idempotency is like calling for the third umpire on the same delivery twice — the review process re-examines that one ball, but the outcome recorded on the scoreboard is identical whether you ask once or ten times. Requesting the review again doesn't add extra runs or wickets; the state of the match stays exactly the same after every repeated call.
Step-by-Step Explanation
Step 1
Define the effect
Focus on server state after the request, not the response body which may differ on repeats.
Step 2
Classify the method
GET, HEAD, OPTIONS, TRACE, PUT, DELETE are idempotent; POST is not; PATCH depends on its body.
Step 3
Design safe retries
Allow clients to retry idempotent requests after timeouts without extra side effects.
Step 4
Guard non-idempotent calls
Attach an idempotency key to POST so retries are de-duplicated by the server.
Step 5
Test with repeats
Send the same request twice and assert the resulting state is identical.
What Interviewer Expects
- A precise definition centered on server state
- Correct list of idempotent methods
- Why POST is not idempotent
- The PATCH nuance about absolute vs relative bodies
- Real use case: safe retries and idempotency keys
Common Mistakes
- Confusing idempotency with the response being identical
- Claiming GET changes state
- Saying DELETE is not idempotent because the second call returns 404
- Assuming all PATCH requests are idempotent
- Mixing up idempotency with safety
Best Answer (HR Friendly)
“Idempotency means you can repeat the exact same request and the server ends up in the same state as if you sent it once. That is why methods like GET, PUT, and DELETE can be safely retried, while POST usually cannot because it creates something new each time.”
Code Example
DELETE /orders/1001
# First call -> 204 No Content (order removed)
# Retry call -> 404 Not Found (state still: order gone)POST /payments
Idempotency-Key: 7c1f-4a20-9be3
Content-Type: application/json
{ "amount": 100, "currency": "USD" }Follow-up Questions
- Why is POST not idempotent while PUT is?
- How do idempotency keys prevent duplicate payments?
- Is DELETE still idempotent if the second call returns 404?
- When is PATCH idempotent and when is it not?
- What is the difference between safe and idempotent methods?
MCQ Practice
1. Which of these methods is NOT idempotent?
POST typically creates a new resource on each call, so repeating it changes state each time and is not idempotent.
2. Idempotency is defined in terms of...
An idempotent request leaves the same server state on repeats, even if the response body or status differs.
3. A second DELETE on an already-deleted resource returns 404. Is DELETE idempotent?
The resource is still gone after both calls, so the state is unchanged and DELETE remains idempotent.
Flash Cards
Define idempotency — Making the same request multiple times has the same effect on server state as making it once.
Which methods are idempotent? — GET, HEAD, OPTIONS, TRACE, PUT, and DELETE.
Why is POST not idempotent? — It usually creates a new resource on each call, changing state every time.
When is PATCH idempotent? — Only when the body sets absolute values, not relative changes like increments.