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 resourceHEAD: the same representation as GET, but without the representation dataPOST: a representation of the status of, or results obtained from, the actionPUT,DELETE: a representation of the status of the actionOPTIONS: a representation of the communications optionsTRACE: a representation of the request message as received by the end serverIf no payload is desired, an origin server ought to send 204 (No Content) instead.
The 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).
For a 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.