FrontendHaltHTTP methods, status codes, and idempotency
Use the right method and status code deliberately, and reason correctly about what idempotency actually guarantees.
WHAT YOU WILL BE ABLE TO DO
Learning outcomes
- Explain http methods, status codes, and idempotency in plain language.
- Connect the behavior to the underlying browser or framework model.
- Implement the core pattern and reason through edge cases.
- Answer common follow-ups without relying on memorized phrases.
01Explain it simply
HTTP methods describe intent — GET reads, POST creates, PUT replaces, PATCH partially updates, DELETE removes — and status codes describe outcome: 2xx success, 3xx redirect, 4xx client error, 5xx server error. Idempotency means repeating the same request produces the same end state as doing it once.
One-line definition: Use the right method and status code deliberately, and reason correctly about what idempotency actually guarantees.
02Mental model
Idempotent doesn't mean 'safe' or 'read-only' — it means calling it multiple times has the same effect as calling it once. GET, PUT, and DELETE are idempotent, so retrying is safe; POST is not, so blindly retrying a failed POST can create duplicates unless the server adds its own deduplication, such as an idempotency key.
03Step by step
- Pick the method by intent: GET to read, POST to create, PUT to fully replace, PATCH to partially update, DELETE to remove.
- Check whether the operation is idempotent before deciding it's safe to retry automatically.
- Match the status code to the actual outcome, not just 200 for everything.
- Distinguish 401 (not authenticated) from 403 (authenticated but not authorized).
- Use 429 with Retry-After for rate limiting instead of a generic error.
04Working example
PUT /api/carts/42/items/7 { "quantity": 3 } // idempotent: same call twice = same end statePOST /api/carts/42/items { "sku": "abc" } // NOT idempotent: same call twice = two items added
// Status codes that matter beyond 200/404:// 201 Created, 204 No Content, 401 Unauthorized, 403 Forbidden, 409 Conflict, 429 Too Many RequestsThe PUT sets item 7's quantity to exactly 3 regardless of how many times it's sent — that's idempotency. The POST appends a new item every time it's called, so a network retry after a timeout could silently add the same item twice unless the client or server guards against it.
05Where it is used
- Designing a REST API's method and status-code conventions
- Deciding whether a failed request is safe for a client to automatically retry
- Distinguishing an auth failure (401) from a permissions failure (403) in error handling
- Implementing rate-limit responses that tell the client when to try again
06Common mistakes
- Assuming POST is safe to retry the same way GET or PUT are
- Returning 200 for every response and putting the real error in the response body instead of the status code
- Using GET for an operation that has side effects, which breaks caching and prefetching assumptions
- Confusing 401 and 403 in error-handling logic, showing a login prompt when the real issue is a permissions problem
07Interview answer
Define idempotency correctly — 'same effect as calling once,' not 'safe' or 'no side effects' — and immediately name which methods qualify; that precision separates a real answer from a memorized list.
Why is it risky for a client to automatically retry a POST request that timed out, but safe to retry a PUT that timed out?
PUT is idempotent, so resending it produces the same final state whether the original request succeeded or not; POST is not idempotent, so if the original request actually succeeded before the timeout, retrying it can create a duplicate resource.
DDConcept deep dives
Deep dive 1
Idempotency is about end state, not safety or side effects
An idempotent operation produces the same result whether it's called once or ten times — that's the entire guarantee. It says nothing about whether the operation has side effects (DELETE clearly does) or is 'safe' to call carelessly. Confusing idempotency with safety is the most common mistake in this area, and it's exactly the distinction that makes automatic retry logic either safe or dangerous.
- GET, PUT, and DELETE are idempotent by convention; POST is not.
- An idempotent operation can still have a real side effect the first time it runs.
- Retry logic must check idempotency, not just 'did this look like a read.'
Deep dive 2
Status codes are a contract, not decoration
A client — whether a browser, a library, or another service — makes real behavioral decisions based on the status code alone, often before it even looks at the response body: caching a 200, following a 3xx redirect, retrying a 5xx, or surfacing a 4xx as a user-fixable error. Returning 200 for everything and encoding the real outcome only in the body breaks all of that built-in behavior and pushes the parsing burden onto every single caller.
- 4xx means the client should change something before retrying; 5xx means the server failed and retrying as-is might work.
- 401 vs. 403 changes what UI a client should show — a login prompt versus a permissions message.
- Reusing a single generic status code for every outcome discards information every HTTP-aware tool already knows how to use.
Deep dive 3
Idempotency keys solve what idempotency itself can't
Because POST and other non-idempotent operations can't rely on the method's own semantics for safe retries, systems that need retry-safety on those operations add their own mechanism: a client-generated unique key sent with the request, which the server uses to recognize and deduplicate a retried attempt rather than processing it again. This is a deliberate application-level fix layered on top of HTTP, not something HTTP provides automatically.
- The key must be generated once per logical attempt and reused across retries of that same attempt, not regenerated each time.
- The server needs to store recent keys for some bounded window to detect duplicates.
- This pattern is common in payment and order-creation APIs specifically because double-submission there is costly.
QAInterview questions and model answers
Attempt each answer aloud before opening it. The model answer shows the depth and precision expected in an interview; it is not a script to memorize.
Beginner · Conceptual · 1 min · Question 1What does it mean for an HTTP method to be idempotent?Open model answer
Model answer
Repeating the same request produces the same server-side end state as sending it once. It says nothing about whether the request has side effects or is safe to call at all — only that repeating it doesn't change the outcome further.
Open question page →Intermediate · Conceptual · 1 min · Question 2Which common methods are idempotent, and which is the notable exception?Open model answer
Model answer
GET, PUT, and DELETE are idempotent by specification convention. POST is not, because calling it again is expected to create another resource or trigger another action rather than converge on the same state.
Open question page →Intermediate · Conceptual · 1 min · Question 3What is the practical risk of a client automatically retrying a timed-out POST?Open model answer
Model answer
If the original request actually reached the server and succeeded before the timeout, an automatic retry can create a duplicate resource or trigger the action twice, since POST has no idempotency guarantee to fall back on.
Open question page →Intermediate · Conceptual · 1 min · Question 4What's the difference between a 401 and a 403 response?Open model answer
Model answer
401 means the request lacks valid authentication — the server doesn't know who you are. 403 means the server does know who you are but has determined you're not authorized to perform that specific action on that resource.
Open question page →Intermediate · Conceptual · 1 min · Question 5Why is using GET for an operation with side effects problematic?Open model answer
Model answer
GET requests are assumed safe and idempotent by browsers, proxies, and crawlers, so they may be prefetched, cached, or retried automatically — any of which would unexpectedly trigger the side effect multiple times or at the wrong moment.
Open question page →Intermediate · Conceptual · 1 min · Question 6What should a 429 response include to be genuinely useful to the client?Open model answer
Model answer
A Retry-After header telling the client how long to wait before trying again, so the client can back off deliberately instead of guessing an interval or retrying immediately and worsening the rate-limit condition.
Open question page →Beginner · Conceptual · 1 min · Question 7What does a 204 No Content response mean?Open model answer
Model answer
The request succeeded, but there is intentionally no response body — commonly used for successful DELETE requests or updates where the client doesn't need any data back.
Open question page →Advanced · Conceptual · 1 min · Question 8What is the purpose of a 409 Conflict status code?Open model answer
Model answer
It signals that the request couldn't be completed because it conflicts with the current state of the resource, such as trying to create a record that already exists with a unique field, distinct from a plain validation failure.
Open question page →Advanced · Conceptual · 1 min · Question 9Is PATCH idempotent?Open model answer
Model answer
Not necessarily — it depends on the semantics of the specific patch operation. A PATCH that sets a field to an exact value is idempotent, but one that increments a counter is not, since repeating it changes the result each time.
Open question page →Advanced · Conceptual · 1 min · Question 10Why do browsers cap how many identical simultaneous connections they'll open to one host?Open model answer
Model answer
It's a resource-management and fairness convention from HTTP/1.1 to avoid one page monopolizing a server's or network's connections; HTTP/2 and HTTP/3 multiplex many requests over a single connection, reducing the practical impact of this limit.
Open question page →SCScenario questions
Scenario 1
A payment submission endpoint occasionally charges a customer twice when their network is flaky and the client automatically retries failed requests.
- Identify that the payment endpoint is implemented as a non-idempotent POST.
- Add an idempotency key generated once per user submission attempt.
- Have the server deduplicate requests sharing the same idempotency key within a time window.
- Keep the client's automatic retry behavior, now made safe by the key.
Reveal worked answer
The root cause is retrying a non-idempotent POST. Rather than disabling retries, which would hurt reliability on flaky networks, I would have the client generate a unique idempotency key per genuine submission attempt and send it with every retry of that same attempt. The server stores recent keys and returns the original result for a duplicate key instead of processing the charge again.