HTTP Idempotency

HTTP idempotency means that making the same request multiple times has the same intended effect on the server as making it once. It matters when clients retry requests because of timeouts, connection failures, or transient network problems.

An HTTP method is idempotent when repeating an identical request does not create an additional intended effect beyond the first successful application. Idempotency describes the server-side effect, not whether every response is byte-for-byte identical.

`GET`, `PUT`, and `DELETE` are defined as idempotent HTTP methods. `POST` is not inherently idempotent, because repeating it can create multiple resources or trigger the same action multiple times.

For example, sending `PUT /users/42` with the same representation repeatedly can leave user 42 in the same state. Repeating `DELETE /users/42` should still leave the resource deleted, although later responses can differ, such as `404 Not Found` after the first deletion.

Idempotency is especially useful for unreliable networks. A client may not know whether a request reached the server when a timeout occurs, so retrying an idempotent operation is generally safer than retrying an operation whose repeated execution creates another side effect.

Applications can also make otherwise non-idempotent operations retry-safe by using an idempotency key or another deduplication mechanism. The server stores enough information to recognize a repeated request and avoid performing the same logical operation twice.

Key points

• Idempotent means repeated identical requests have the same intended server effect as one request.
• `GET`, `PUT`, and `DELETE` are idempotent HTTP methods; `POST` is not inherently idempotent.
• Idempotency does not require identical response status codes or response bodies.
• Idempotency helps make retries safer when network failures leave request completion uncertain.
• An application can add retry safety to operations such as `POST` with an idempotency key.

Interview questions

What does idempotency mean in HTTP?

An HTTP operation is idempotent when repeating the same request has the same intended effect on server state as performing it once. It does not mean that every response must be identical. This property is useful when clients need to retry requests after uncertain network failures.

Which common HTTP methods are idempotent?

`GET`, `PUT`, and `DELETE` are defined as idempotent HTTP methods. `POST` is not inherently idempotent. `PATCH` is not generally guaranteed to be idempotent because its effect depends on the particular patch operation.

Why can DELETE be idempotent even though the second request may return 404?

Idempotency concerns the intended effect on the resource, not whether responses are identical. After the first successful deletion, the resource is absent; repeating the deletion leaves it absent. The second request can therefore produce a different response while preserving the same intended state.

How would you make a POST request safe to retry?

A common approach is to require an idempotency key supplied by the client. The server associates that key with the logical operation and records the result or enough state to detect a duplicate. If the same key is received again, the server avoids performing the operation a second time and can return the previously recorded result.

What is the difference between idempotency and exactly-once delivery?

Idempotency does not guarantee that a request is physically processed only once. A server might receive or execute the request more than once but use deduplication so the externally visible effect occurs only once. Exactly-once processing is a broader distributed-systems property involving delivery, execution, and failure semantics.