2xx success

It worked, but how?

We have covered HTTP methods. Now we need to talk about what the server says back. The status code is the first thing the client checks when it gets a response, and 2xx codes mean the request succeeded. But “success” is not just one thing. Did the server return data? Did it create something new? Did it complete an action but have nothing to say about it? Each of these is a different kind of success, and each gets its own status code.

Using the right 2xx code is not just a nice convention. It tells the client exactly what happened so it can respond appropriately. This is how production APIs communicate.

200 OK

The most common status code you will ever see. The request succeeded and the response body contains the result.

HTTP/1.1 200 OK
Content-Type: application/json

{"id":"book-1","title":"Kindred"}

Use 200 for: GET requests that return data, PUT or PATCH requests that return the updated resource, or really any successful request where you are sending a body back. When in doubt, 200 is the safe default for “it worked.”

201 Created

This one is specifically for when the server creates something new. The response should include the created resource and a Location header pointing to it.

HTTP/1.1 201 Created
Content-Type: application/json
Location: /books/book-6

{"id":"book-6","title":"Parable of the Sower"}

Remember in the POST lesson when the server responded with 201 Created? That was not arbitrary. It is the convention: POST creates a resource, the server responds with 201. The Location header is a nice touch because it tells the client where to find the new resource without having to dig through the response body.

What makes 201 different from 200? Intent. 200 says “here is data.” 201 says “something new was created that did not exist before.”

204 No Content

Sometimes the request succeeds but there is nothing useful to send back. That is 204. No body at all.

HTTP/1.1 204 No Content

Use 204 for: successful DELETE requests (the resource is gone, there is nothing to return), PUT or PATCH requests where you do not need to send the updated resource back, or any action that worked but has no meaningful response data.

Here is a common gotcha: what happens if a client calls response.json() on a 204 response? It throws an error, because there is no body to parse. You should always check the status code before trying to read the body. We will see more of this in the “No body” lesson later.

202 Accepted

This one is less common but very useful. 202 means “I received your request and I will process it, but I have not finished yet.”

HTTP/1.1 202 Accepted
Content-Type: application/json

{"jobId":"job-123","status":"queued"}

This shows up when the server kicks off a background job instead of doing the work immediately. The server is saying “your request is in the queue, come back later to check on it.” This is exactly the pattern used in the Background Jobs course for things like order processing.

[!NOTE] The Background Jobs course builds on this status code. When the user places an order, the server responds with 202 and processes the order asynchronously.

Picking the right one

The pattern is simple. If you are returning data, use 200. If you created something, use 201. If there is nothing to return, use 204. If the work happens later, use 202.

Not every success looks the same, and the next lesson covers the opposite scenario: 3xx codes, when the resource has moved somewhere else.

Exercises

Exercise 1: Create a resource with POST. Verify the response is 201 with a Location header.

Exercise 2: Delete a resource. Verify the response is 204 with no body.

Exercise 3: Build an endpoint that returns 202 Accepted with a job ID, simulating a background job.