200 vs 201 vs 204 Status Codes
Fast recall
Quick revision
Core answer
200 OK when a completed request returns useful content, 201 Created when the completed request created one or more resources, and 204 No Content when the request succeeded but there is no response content to send. Choose from the result, not from the HTTP method alone.Interview-ready guide
Interview answer
All three codes mean success, but they promise different results. Start with two questions: did this request create a resource, and does the response contain a representation? Do not choose a code only because the request used GET, POST, PUT, or DELETE.
Use 200 OK when the work is complete and the response returns useful content. A successful GET /orders/42 can return order 42. An update can also return 200 with the updated order, and a POST that runs a calculation can return 200 with the calculated result even though it created no resource.
Use 201 Created when the request has completed and created one or more resources. After POST /orders, a Location: /orders/42 header can point to the main new order, and the body may contain its representation. A Location header is useful but is not required in every 201; if it is absent, the request URI identifies the primary created resource. PUT may also return 201 when it creates the target for the first time.
Use 204 No Content when the work is complete and nothing needs to be sent in the response content. It is common after a delete or an update where the client already has what it needs. Headers such as ETag may still describe the resulting state, but a 204 response cannot contain JSON or any other message content.
A PUT to /profiles/42 shows the full choice. If it creates profile 42, return 201. If it replaces an existing profile and sends the new representation, return 200. If the update succeeds with no content, return 204. If work has only been queued and is not complete, use 202 Accepted instead of any status that promises completion.
200 vs 201 vs 204 Status Codes
Direct Answer
Use 200 OK when a completed request returns useful content, 201 Created when the completed request created one or more resources, and 204 No Content when the request succeeded but there is no response content to send. Choose from the result, not from the HTTP method alone.
Deep Dive & Architecture
The HTTP method tells the server what the client wants. The response status tells the client what actually happened. That small distinction explains why hard rules such as “POST is always 201” and “DELETE is always 204” fail. POST may run an action without creating a resource, while PUT may create one.
A useful API contract also tells the client where a created resource lives. In a 201 response, Location identifies the primary new resource when the server sends that header. Content-Location has a different meaning: it identifies the resource represented by the response content. The values can match, but the headers do not mean the same thing.
A 204 response is deliberately empty. The client should process its headers and stop; it should not try to parse a body. If an update needs to return the changed object, warnings, or another representation, 200 is the clearer choice. If the request only entered a queue, 202 says that processing has not finished yet.
Code Example
Created resource
HTTP/1.1 201 Created
Location: /orders/42
Content-Type: application/json
{"id": 42, "status": "pending"}
Successful update with no response content
HTTP/1.1 204 No Content
ETag: "order-v2"
Check your understanding
Answer these without looking back at the article.
- Can PUT return 201 Created?
- Is Location mandatory on every 201 response?
- Can a 204 response contain a JSON body?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.