Idempotent HTTP Methods in REST – Complete Interview Guide

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.

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" }

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.

Keywords they're listening for: