Status codes for successful POST and GET

WHAT THIS TESTS This checks whether you use HTTP status codes meaningfully rather than defaulting everything to 200.

A GOOD ANSWER COVERS For a successful POST that creates a resource, the most appropriate code is 201 Created. It tells the client a new resource was successfully created, and best practice is to include a Location header pointing to the new resource's URL and to return the created representation in the body. For a successful GET that returns data, the correct code is 200 OK, the standard success response indicating the request succeeded and the body contains the requested data. Using accurate codes lets clients, caches, and tooling reason about responses without parsing the body.

COMMON WRONG ANSWERS Returning 200 for a creation; it works but loses the semantic signal that a resource was created. Using 204 No Content while still sending a body, which is contradictory since 204 means there is no body. Returning 201 for a GET. Returning 200 for an async creation that should be 202 Accepted. Treating all 2xx codes as interchangeable.

LIKELY FOLLOW-UPS When would you use 202 Accepted? What about 204 for a DELETE? What header accompanies a 201? Why do precise codes matter for clients and caches?

ONE CONCRETE EXAMPLE A POST /orders that synchronously creates an order returns res.status(201).location('/orders/abc').json(order). A GET /orders/abc returns res.status(200).json(order). By contrast a DELETE /orders/abc that succeeds with no response body would correctly use 204 No Content, illustrating how each code communicates a distinct outcome rather than just success.