Which success status codes are appropriate for POST, PUT and DELETE responses, and what does the Location header mean in that context?

## Why the codes matter Status codes are the machine-readable part of the response, and generic clients — SDK layers, gateways, dashboards, caches — act on them without reading your body. Getting them right per method is what lets a client distinguish "created", "done, nothing to say", and "accepted, ask later" without parsing JSON. ## POST POST means "process this representation", so its success code depends on what the processing did. - **201 Created** — one or more resources came into existence. RFC 9110 says the primary resource created is identified by the `Location` header field, or by the request URI when no `Location` is given. Send the created representation in the body too; clients then avoid an immediate follow-up GET. Adding an `ETag` lets the client make its next update conditional. - **200 OK** — processing produced a result that is not a new resource: a computed total, a validation report, a search result set. - **202 Accepted** — the request was accepted but processing is **not complete**, and may not even succeed. 202 is a promise to try, nothing more, so it must come with a way to find out: a `Location` (or a body link) pointing at a status/job resource the client can poll. Returning 202 with no handle is a common design bug — the client is told "maybe" with no way to resolve it. - **204 No Content** — the action succeeded and there is deliberately nothing to send back. A subtlety worth mentioning: 201 responses are the natural place for `Location`, and clients should not have to guess the new id from a body field whose name varies per endpoint. ## PUT PUT targets a URI the **client** already chose, which changes the reporting: - **201 Created** — the target did not exist and the PUT created it. `Location` is unnecessary because the request URI *is* the resource's URI; sending it is harmless but redundant. - **200 OK** — an existing resource was replaced and you are returning the resulting representation. This is the friendliest option: the client sees exactly what the server stored, including server-computed fields (normalised values, timestamps, version). - **204 No Content** — replaced successfully, nothing returned. Efficient, and fine when the client already knows the full state. With either 200 or 204, return the new **`ETag`** so the client can immediately issue its next conditional write with `If-Match` without re-reading. What PUT should *not* return: 202 for a synchronous replace (it makes clients poll for nothing) or 200 with a body that silently differs from what was sent without explanation. ## DELETE - **204 No Content** — the default and most common: deleted, nothing to say. - **200 OK** — you are returning something useful, such as the deleted representation or a summary ("3 child records removed"). - **202 Accepted** — deletion was queued (large cascades, background purges, eventual consistency across regions). Again, provide a status handle. The recurring debate is **deleting something already gone**. Two consistent policies exist. Report **404** (or **410** if you keep tombstones), which is literal and helps catch client bugs; or report **204** on the grounds that the desired end state — resource absent — holds, which makes client retries painless. Either is defensible; what matters is picking one and applying it uniformly, and documenting it, because a retrying client behind a flaky network *will* hit this. ## Location: two different jobs `Location` appears in two very different contexts: 1. On **201 Created**, it identifies the **newly created resource**. 2. On **3xx redirects**, it identifies the **target to go to instead**. 3. On **202 Accepted**, it conventionally points at a resource representing the *status of the request*, not the eventual result. Same header, three readings, disambiguated entirely by the status code. Note also the contrast with **`Content-Location`**, which tells the client the URI of the representation *in this message* — useful on a POST or PUT response to say "this body is also retrievable at that URI". ## Response bodies and caching A 204 must have **no body** — sending one is a protocol violation that some clients and intermediaries handle badly. 200 and 201 may carry bodies. State-changing responses should generally not be cached; when a shared cache sees an unsafe method it invalidates stored responses for the effective request URI, but explicit `Cache-Control: no-store` on sensitive responses is still the safe habit. ## Putting it together The answer an interviewer wants is a small table plus the reasoning: creation → 201 + `Location`; asynchronous → 202 + status handle; result to return → 200; nothing to return → 204; and a stated, consistent policy for repeated DELETEs.