HTTP & APIs Interview Questions: REST Idempotency

A GET request only retrieves a representation of a resource and does not modify server-side state, so repeating the identical request yields the same observable result as sending it once. Idempotency is defined by the effect of repeated identical requests on the server, and a GET has no such effect, so the statement is true.

POST is the canonical non-idempotent HTTP method: each identical POST can create a new resource or trigger a new side effect, so repeating it changes the outcome. GET is a read-only retrieval, PUT replaces the same target resource state each time, and DELETE removes the same resource each time, all producing the same end state regardless of repetition. Restricting the question to these four methods avoids PATCH, whose idempotency depends on the patch document.

An idempotent HTTP method is one where sending the same request multiple times has the same effect as sending it once. GET, PUT, and DELETE are idempotent: repeated GETs return the same resource state, repeated PUTs set the resource to the same target state, and repeated DELETEs leave the resource deleted. POST is not idempotent because each request typically creates a new resource, so sending it twice creates two resources rather than one.

Idempotency means that repeated identical requests do not change the server's resource state beyond the effect of the first request. This property lets clients safely retry a request (for example, after a network timeout) without worrying about duplicating side effects. GET, PUT, and DELETE are the classic idempotent methods, while POST is not.

PUT is idempotent because it replaces the target resource with the representation in the request, so repeating the same PUT leaves server state the same as a single call. POST is not idempotent because it typically creates a new resource on each call. PATCH is not guaranteed idempotent because it applies a change set that may be additive, so repeating it can change the result. CONNECT establishes a tunnel and is not idempotent. PUT is therefore the only idempotent method in this set.

RFC 9110 states that PUT, DELETE, and the safe methods are idempotent; the safe methods are GET, HEAD, OPTIONS, and TRACE, giving six idempotent methods in total. Idempotency is judged by the effect on server state, so repeated identical requests must leave the same end state as one request. POST is not idempotent because it typically creates a new subordinate resource on each request, so repetition creates more resources. PATCH is not idempotent by definition in RFC 5789 because a patch document may express relative changes such as appending or incrementing, whose effects accumulate when repeated.

Idempotency means that repeated identical requests have the same effect on server-side state as a single request. PUT meets this even when it creates a resource, because every identical PUT leaves the resource in the same state. POST can create duplicate records when repeated, and PATCH is not guaranteed idempotent by its definition, since only some PATCH operations (such as full replacement) are. Idempotency concerns the effect on state rather than the response body, so requiring identical response bodies is not part of the definition.

The statement is true. RFC 9110 defines idempotency by the effect a request has on server-side resource state, not by the response it receives. Repeating a DELETE leaves the resource absent in the same way as a single DELETE, so the state is identical. The first request returning 200 and a repeat returning 404 does not change that, so DELETE is idempotent.

RFC 9110 lists the idempotent methods as GET, HEAD, OPTIONS, TRACE, PUT, and DELETE; POST is not one of them, and no header defined in the specification changes that. The Idempotency-Key header is a de facto convention popularized by payment APIs such as Stripe, not part of HTTP/1.1, HTTP/2, or RFC 9110-9114. It does not alter the formal semantics of POST. The guarantee comes from server-side logic: the server stores the response for a given key and replays it for duplicate requests instead of re-executing the operation. The statement is therefore false.

The retry is safe because the server ties the client's unique key to the outcome of the first attempt. On the first request the server records the key with the stored response; on any retry carrying the same key, it finds the record and replays that response instead of charging again. The required storage property is durability: the key-to-response mapping must live in a shared, persistent store (such as a database) rather than process memory, so that it survives restarts and is visible to every instance behind a load balancer. Without that, a retry routed to a different instance or after a restart would find no record and charge the customer a second time.

Per RFC 9110, a safe method is one whose semantics are read-only, and safe methods are also idempotent, so GET is both safe and idempotent and fails the 'not safe' condition. POST is neither safe nor idempotent. PATCH (RFC 5789) is listed in the IANA HTTP Method Registry as not idempotent, because applying the same patch document to different resource states can yield different results. PUT is idempotent, since repeated identical PUT requests leave the resource in the same state, but it is not safe because it changes the state of the target resource. The question is limited to the listed choices, so DELETE, which shares the same idempotent-but-not-safe property, does not appear.

Idempotency keys work by having the server persist a mapping from the key to the full response of the first request. On a retry with the same key, the server short-circuits processing and returns the stored response, which guarantees the side effect (charge creation) happens exactly once. This pattern matters for non-idempotent methods like POST, where a naive retry would create a duplicate charge.

The whole point of an idempotency key is to make an unsafe operation (POST of a charge) safe to retry: the server records the key together with the response it produced, and a later request bearing the same key replays that stored response verbatim instead of re-executing the side effect. So the timed-out retry gets the original 200 and the card is charged once. The option that describes plain stateless HTTP defeats the mechanism — it would double-charge. The option that says a repeated key is a malformed, duplicate request is wrong because a repeated key is exactly the expected, supported case, not a client error. The option that says to respond 409 Conflict is the tempting trap: 409 Conflict is the right answer only for the different scenario where a second request with the same key arrives while the first is still in flight — the server locks on the key and rejects the concurrent duplicate. For a replay of an already-completed request there is nothing in conflict; the server simply returns the cached original result.

GET, PUT, and DELETE are idempotent: repeating PUT re-sets the same state, and repeating DELETE leaves the resource deleted (the later calls may return 404, but the server state is unchanged). POST is not idempotent — each call typically creates a new resource, which is why retries need an idempotency key (RFC 9110 §9.2.2).

The guarantee breaks because the key is recorded only after the side effect. The read (store.get), the charge, and the write (store.set) are three separate awaits with no lock and no atomic reserve. Two retries that arrive close together both run store.get before either has called store.set, both see no existing record, and both call gateway.charge — a double charge. The fix is to atomically reserve the key before charging (e.g. an INSERT … ON CONFLICT DO NOTHING / conditional put that the second request loses, or a row lock on the key), so a concurrent duplicate is detected up front and either waits for or replays the first result. The claim that the handler must use PUT is wrong: HTTP method semantics describe intent, they do not enforce at-most-once execution — PUT would have the identical race. The claim that replaying a stored response must use 200 OK is wrong: replaying the original response means returning the original status, including 201; rewriting it to 200 would misreport what happened. The claim that the server should generate the key itself is an actively harmful trap: the key must be minted by the client and held stable across attempts — that stability is what links a retry to its original. A server-generated key would differ on every attempt, so no two retries would ever match and deduplication would be impossible.

Idempotency is about the effect on server state, not the response body: repeating an idempotent request leaves the same state as a single call (RFC 9110 §9.2.2). Safe methods are a subset — all safe methods are idempotent. This property is what makes automatic retries of GET/PUT/DELETE safe, while POST retries need an idempotency key to avoid duplicate side effects.

RFC 9110 §9.2.2 defines idempotency by comparing the effect of one request with the effect of multiple identical requests. The profile resource includes update_count, and the handler increments it on every call, so one PUT leaves the value at N while two identical PUTs leave it at N+1. Because the resource state changes with each repetition, the endpoint is not idempotent. The PUT method's default expectation does not override this: idempotency depends on what the handler actually does to the resource, not on the method name.

The code does SELECT ... WHERE key = ? then conditionally INSERT ... in Python. There is no database-level uniqueness constraint on the idempotency key column and no transaction or lock protecting the gap between the two statements. Two concurrent requests with the same key can both execute the SELECT, both find no existing row, and both proceed to INSERT and charge, so the bug is a TOCTOU (time-of-check-to-time-of-use) race between the SELECT existence check and the INSERT write. The fix is to enforce a UNIQUE constraint on the idempotency key column and catch the resulting integrity-error on INSERT, or to use INSERT ... ON CONFLICT so the database serializes the check atomically.

Safety and idempotency are distinct semantic properties defined in RFC 9110. A safe method is read-only and produces no observable state change, which makes it suitable for caching and prefetching; GET, HEAD, OPTIONS, and TRACE are safe. Idempotency is weaker: repeating a request has the same effect as sending it once. GET, HEAD, OPTIONS, TRACE, PUT, and DELETE are idempotent. PUT and DELETE are idempotent but not safe because they modify state while repeating the same replacement or deletion leaves the same final state. POST is neither because each request may create a distinct resource or trigger a unique side effect. RFC 5789 states that PATCH is neither safe nor idempotent, since a partial modification such as incrementing a counter gives a different result when applied twice.

The Idempotency-Key pattern is a server-side convention layered on top of the non-idempotent POST method, since HTTP itself does not define this header. The client generates a unique key and reuses it on retries. The server persists the key with the request and the complete response it produced, and on a repeated key it replays that stored response, including the original status. For an order that was successfully created, the replay therefore carries 201 Created, not 200 OK, because the stored response is returned verbatim and no new operation is executed.

Per RFC 9110 section 9.2, idempotency is defined by the intended effect on server state: making the same request N times should leave the server in the same state as making it once. It places no requirement that responses match. The first PUT creates the resource, so 201 Created is correct (RFC 9110 allows PUT to return 201 when it creates a resource). The retry finds the resource already in the target representation, so the server answers 200 OK and changes nothing, which is exactly what idempotency requires. The status difference reflects the server's knowledge of the prior creation, not a second state transition. POST is not idempotent by definition, so moving to POST would make the non-idempotency real rather than fix it.

Per RFC 9110 §9.2.2, a request method is idempotent when multiple identical requests with that method have the same intended effect on server state as a single such request. The specification explicitly says the idempotent property applies only to what the user requested, and the server may separately initiate actions independent of the request, such as logging, without violating idempotency. The statement about logging and counters is therefore the true one. The statement that idempotent methods must be safe is false, since PUT and DELETE are idempotent but not safe. POST is not defined as idempotent, and the specification does not require identical response bodies across repeated requests.

RFC 9110 defines idempotency as a property of server state — identical requests, whether issued once or N times, leave the server in the same state — not as identical responses. DELETE and PUT are idempotent methods: after two identical DELETE calls the resource is gone just as it was after the first, and after two identical PUT calls with the same body the resource content is the same as after one. The differing status codes (200→404 for DELETE, 201→200 for PUT) are fully conformant because the RFC states that idempotent requests 'might not have the same response.' POST /widgets/{id}/views is non-idempotent: each call mutates the counter, so the server state after two calls differs from after one. The GET statement is false because the RFC explicitly acknowledges that 'it is not possible to ensure that the server does not generate side effects while handling a request' — safety concerns the requested semantics (read-only intent), not a prohibition on all server-side side effects. The POST /widgets statement is false because POST is not idempotent per the spec; there is no protocol-level requirement to deduplicate or return the same resource id on retry — preventing duplicates is an application-level concern typically handled with an Idempotency-Key header or a uniqueness constraint.

The three correct statements are the PUT claim, the DELETE claim, and the POST-with-Idempotency-Key claim. RFC 7231 section 4.2.2 defines PUT as idempotent because the intended effect of a full replacement is the same whether it is sent once or many times, and it names DELETE as idempotent because repeating a delete leaves the resource absent; a second DELETE returning 404 does not change server state. The Idempotency-Key convention makes a retried POST safe by returning the stored original response instead of re-running the operation. The PATCH claim is wrong because RFC 5789 explicitly says PATCH is not required to be idempotent; a particular patch document may happen to be idempotent, but that is a property of the document, not a method-level guarantee. The JSON Patch claim is wrong because an add to /tags/- appends on every application, so applying it once yields ['vip'] and applying it twice yields ['vip','vip'], which differ.