Idempotent HTTP Methods in REST – Complete Interview Guide

“Which HTTP methods are idempotent and why does it matter?”

Idempotency is about the effect on server state, not about the HTTP response looking identical every time. Calling an idempotent operation once or five times in a row should leave the resource in the same state as calling it once.

Safe and idempotent are different HTTP properties — safe does not mean idempotent. Safe means the request isn't intended to modify server state (GET, HEAD, OPTIONS). Idempotent means repeating the same request has the same intended effect on server state, whether or not that request is safe. From the table above: GET is both safe and idempotent; PUT and DELETE are idempotent but not safe (they do change state); POST is neither.

PUT /users/101
Content-Type: application/json

{ "name": "John" }

# Call this 5 times in a row -> user 101 still just has name "John".
# The resource ends up in the same state either way.

POST /users
Content-Type: application/json

{ "name": "John" }

# Call this 5 times in a row -> 5 new user resources are created.
# POST is not inherently idempotent - each call has an additional effect.

DELETE is idempotent in terms of state, not status code. The first DELETE /users/101 typically returns 204 No Content; repeating it usually returns 404 Not Found because the user is already gone. The responses differ, but the server ends up in the same state either way (user 101 doesn't exist), and that end state is what idempotency measures.

Is PATCH idempotent? It depends entirely on what the patch operation does — PATCH has no inherent guarantee either way. A replace-style PATCH that sets a field to an absolute value is idempotent. An increment-style PATCH that applies a delta is not.

PATCH /orders/55
Content-Type: application/json

{ "status": "shipped" }

# Idempotent: call this 5 times -> order 55's status is "shipped" either way.
# It sets an absolute value, not a delta.

PATCH /accounts/9
Content-Type: application/json

{ "balance": { "$inc": 500 } }

# NOT idempotent: call this 5 times -> balance goes up by 2500, not 500.
# It applies a delta, so repetition compounds the effect.

In production, clients don't always know whether a request succeeded. A network timeout can happen after the server already processed the request — the client only knows the response never arrived, not whether the operation ran. So it retries.

Client
  |
  | POST /payments
  v
Server processes payment
  |
  | response lost / timeout
  v
Client retries
  |
  | POST /payments
  v
Potential duplicate payment

POST /payments
Idempotency-Key: 8f14e45f-ea...
Content-Type: application/json

{ "amount": 5000, "currency": "INR" }

1. Generate

Client generates a unique idempotency key per logical operation

2. Receive

Server receives the request with the Idempotency-Key header

3. Check

Server checks whether that key was already processed (Redis, DynamoDB, or a relational table — key → result)

4. Process

If not processed yet, the server executes the operation

5. Store

The result is stored against the key

6. Replay

If the same key arrives again, the server returns the stored result instead of re-executing

Idempotency-Key
        ↓
Lookup existing result
        ↓
Already processed?
   ↙             ↘
 YES             NO
  ↓               ↓
Return result   Process request
                  ↓
              Store result

Simple analogy: setting a thermostat to 22°C is idempotent — setting it once, or five times, leaves the room at the same target temperature. Compare that to "add ₹500 to my account" — repeating that instruction five times adds ₹2,500, not ₹500. Same-looking request, very different behavior under repetition — that's exactly the difference idempotency captures.

A payment client sends POST /payments, the network stalls, and the client times out without knowing whether the charge went through. Without an idempotency mechanism, retrying risks a duplicate charge. With an Idempotency-Key, the retry carries the same key — the server recognizes it already processed that operation and returns the original result instead of charging the customer again. This is exactly why banking and payment APIs (Stripe and most payment gateways) require an idempotency key on POST /payments-style endpoints.

Keywords they're listening for:

• ✓ GET, PUT, DELETE are idempotent
• ✓ POST is not inherently idempotent
• ✓ PATCH depends on the implementation
• ✓ Safe and idempotent are different properties
• ✓ DELETE stays idempotent even if the 2nd call returns 404
• ✓ Idempotency-Key makes POST safely retryable
• ✓ Persist the key atomically before processing

• ✗Saying "POST and PATCH are not idempotent" as a blanket rule — POST isn't inherently idempotent, PATCH depends on what it does
• ✗Confusing Safe with Idempotent — they're different HTTP properties
• ✗Assuming idempotent means the HTTP response must be identical every time
• ✗Skipping Idempotency-Key on retryable POST endpoints (payments, order creation)
• ✗Processing the request before persisting the idempotency key, leaving a race window for concurrent retries

• ✓Use PUT for full replacement; it's naturally idempotent
• ✓Add an Idempotency-Key to any POST that creates side effects and might be retried
• ✓Persist the key atomically (DB unique index or Redis SETNX) before processing, not after
• ✓Document exactly what a PATCH operation does and whether it's safe to retry
• ✓Judge idempotency by effect on state, not by whether the response looks the same

1. 1What does idempotent mean in REST?
2. 2Which HTTP methods are idempotent?
3. 3What is the difference between Safe and Idempotent?
4. 4Is DELETE idempotent if the second request returns 404?
5. 5Can PATCH be idempotent?
6. 6Why is POST not inherently idempotent?
7. 7How can POST be made idempotent?
8. 8What is an Idempotency-Key?
9. 9Why is idempotency important in distributed systems?
10. 10Why is idempotency especially important for payment APIs?

• Idempotency-Key
• Redis SETNX
• DB unique index
• Stripe idempotency
• RFC 9110

• RFC 9110 §9.2.2 — HTTP Semantics: Idempotent Methods ↗ (opens in a new tab)