What is the difference between HTTP status codes 200, 201, and 204?

Think about two questions: did the request create a resource, and is the server returning response content?

1. 200 OK says the request succeeded. Its precise meaning depends partly on the method: a GET commonly returns the retrieved resource in the body. A successful POST can also return a body describing its result. A 200 alone does not say that anything was created. [S1]
2. 201 Created says the request resulted in a new resource. The response may include the resource or a description of it; the resource must be locatable through the request URL or a URL in the Location header. [S2]
3. 204 No Content says the request succeeded and supplies no response content. Its response must not contain a body. [S3]

So don’t choose based only on whether the method is GET, POST, PUT, or DELETE. Base the status on the outcome and the content your response actually provides.

Suppose an API manages tasks. These are illustrative scenarios, not rules that every API must follow:

• GET /tasks/42 finds and returns a task: 200, with the task in the response body.
• POST /tasks creates a task: 201, because the request created a resource. The response can include the task or describe it and identify where it can be located, such as with a Location header. [S2]
• DELETE /tasks/42 succeeds without returning anything: 204, with no response body. DELETE is one example, not the only method that can use 204; PUT can also succeed with no content. [S3]

A successful POST that returns a result description can use 200 if the request succeeded but the outcome is not resource creation. The method alone does not settle the choice. [S1]

First decide whether the client needs content back. If the update succeeded and your API returns the updated representation—or another response body—200 is a suitable success signal. If it succeeds and you return no content, 204 communicates that explicitly; do not attach a body to a 204 response. [S1] [S3]

For example, if PUT /tasks/42 updates a task and returns its updated fields, you could use 200. If it updates the task but returns nothing, you could use 204. These are example designs: the status definitions explain the meanings, but they do not prescribe the response contract for your particular API. Check that contract and keep the choice consistent across similar operations.

Use this order:

1. Did the request succeed? If not, these three success codes are not the answer.
2. Did it create a resource? If yes, consider 201 and make the new resource locatable through the request URL or a Location URL. [S2]
3. Will the response include content? For a successful response with content that did not create a resource, consider 200. [S1]
4. Did it succeed with no response content? Consider 204, and make sure its response body is empty. [S3]
5. Does the API contract use the code consistently? Check how clients are expected to interpret the response.

Worked example: an endpoint creates a task and returns its details → 201. An endpoint fetches that task and returns it → 200. An endpoint removes it and returns no content → 204. The status meanings help describe the outcome; they do not establish what a particular API actually does, so verify the endpoint’s documented behavior.