HTTP Methods — Idempotency

NetworkingMidnetworking

The Question

Which HTTP methods are idempotent and why does it matter?

What a Strong Answer Covers

• Correct for each method
• PATCH not guaranteed
• define idempotent

Senior-Level Answer

An HTTP method is **idempotent** if making the same request N times produces the same server state as making it once. It is **safe** if it does not modify server state at all. These properties are not just academic—they directly determine whether a client or proxy can safely retry a request after a network failure.

**Safe methods**: GET, HEAD, OPTIONS, TRACE. Because they have no side effects, they can be retried, cached, and prefetched without concern.

**Idempotent but not safe**: PUT, DELETE. PUT replaces a resource with the supplied representation; sending it twice results in the same final state as sending it once. DELETE removes a resource; a second DELETE on an already-deleted resource should return 404 or 204, but the server state is the same (resource absent). These cannot be cached but can be retried safely on timeout.

**Neither idempotent nor safe**: POST, PATCH. POST typically appends or creates a new resource—sending it twice creates two resources. PATCH applies a partial update; the semantics depend on the operation (an increment patch is not idempotent, a set patch could be). Clients must not auto-retry POST without idempotency keys.

**Why it matters in practice**: Load balancers and service meshes use idempotency to decide retry policy. A timed-out GET can be retried immediately; a timed-out POST cannot without risking duplicate processing (double charges, duplicate orders). This is why payment APIs like Stripe require an `Idempotency-Key` header on POST requests—it allows safe retries by making POST behave as idempotent at the application layer.

Distributed systems also rely on this property for at-least-once delivery. Message consumers processing HTTP callbacks must treat POST payloads as potentially duplicated and implement deduplication logic (storing processed IDs) when the operation is not naturally idempotent.

A common confusion is between idempotency and the HTTP response code: a second DELETE returning 404 instead of 204 does not violate idempotency—idempotency is about server state, not response equality.

Key Differences

What Separates a 2/3 from a 3/3

Common Mistakes

• Conflating 'safe' with 'idempotent'—GET is both; DELETE is idempotent but not safe.
• Claiming DELETE is not idempotent because a second request returns 404—idempotency is about state, not response code.
• Treating PATCH as always non-idempotent without noting that set-style patches (set field = value) are idempotent.
• Forgetting that idempotency properties inform load balancer and service mesh retry configuration.

Follow-Up Questions

• How does an idempotency key work for a payment POST request? — Client generates a UUID per intent; server stores (key → result) and returns the cached result on duplicate keys.
• If a PUT request times out and the client retries, what could go wrong if the server processed the first request? — Nothing—PUT is idempotent, the state is the same. Contrast with POST where a duplicate creates two resources.
• How would you make a POST endpoint idempotent at the application layer? — Accept an idempotency key header, persist it with the result, return the cached result for duplicate keys within a TTL.
• Why does HTTP PATCH not have a guaranteed idempotency property? — PATCH semantics depend on the operation: 'increment by 1' is not idempotent; 'set status to active' is.

Related Questions

• TCP — 3-Way Handshake
• TLS — Certificate, DH, AES
• TCP vs UDP
• HTTP vs HTTPS
• WebSockets