The 200 (OK) status code indicates that the request has succeeded.
The payload sent in a 200 response depends on the request method. For the methods defined by this specification, the intended meaning of the payload can be summarized as:
GET: a representation of the target resource
HEAD: the same representation as GET, but without the representation data
POST: a representation of the status of, or results obtained from, the action
DELETE: a representation of the status of the action
OPTIONS: a representation of the communications options
TRACE: a representation of the request message as received by the end server
If no payload is desired, an origin server ought to send 204 (No Content) instead.
200 is the standard successful response for when you’re returning some kind of a body in the response. If you don’t have a body, one of the other 200-level status codes is more appropriate.
What you should return in the body of a
200 aligns with the “meaning” of the HTTP method used for the request.
For instance, with a
GET request, the expectation is that you’re returning the representation that the user asked for. So, if the route is
/book/1 the expectation is that you return whatever your representation of a Book is (JSON, html, whatever).
POST, you’re often returning the thing that the user changed. If a
book has a new title, you’re returning the book with the new title in place.
For something like a
DELETE, the actual resource is gone, and so the response is usually some indication that the delete action has been successful.
Cachable by default. Usually only cached on the GET.