HTTP 200 OK – Free, Online, Private

What HTTP 200 means

200 is the general success status. For GET it means a representation of the resource is in the body. For POST it often means the action finished and the body describes the result, as opposed to 201 where a new resource was created or 204 where there is nothing to say. The status does not mean 'the boolean in the JSON is true'. An error object with HTTP 200 is a contract bug.

200 OK belongs to the 2xx successful class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 200

When you see HTTP 200 OK, stop on that exact status line. 200 OK means the request succeeded and the response represents the result. The trace that usually produces it: GET found the resource and the body is its current representation. The 2xx successful class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Return 200 when the request succeeded and you have a body the client should read. Prefer 201 when a resource was created, 202 when the work is only queued, and 204 when there is deliberately no body. Do not return 200 for a failure you encoded inside the JSON.

How to fix HTTP 200

To fix HTTP 200, change the condition that made the server choose OK. Read the body according to Content-Type. Treat 200 as success. If your API hides errors inside 200, the client has to special-case that API. New APIs should not. A successful 200 does not need a retry. If the connection died before you read the body, retry a GET. Retrying a POST can repeat the action. If the log line is a different code, leave this page. The mix-up people make with 200 is this one: 201 is the status when a new resource exists and Location points at it. 204 is the status when success has no body. 200 with an empty body makes clients guess.

• POST completed and the body is the outcome, not a new resource URL.
• A handler returned 200 by default even though it wrote an error message.
• A cache returned a stored 200 that is now stale because validators were missing.

An access log that only stores 200 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

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

{"id":42,"name":"Ada"}

Content-Type tells the client how to read the body. A missing type invites sniffing. The body is the representation. If you have nothing to return, 204 is the status that says so without an empty JSON object pretending to be a document.

What the client should do

Read the body according to Content-Type. Treat 200 as success. If your API hides errors inside 200, the client has to special-case that API. New APIs should not.

GET responses are cacheable by default unless Cache-Control says otherwise. POST responses are not cached by default. Set Cache-Control when a 200 must not be stored, especially if it contains private data.

A successful 200 does not need a retry. If the connection died before you read the body, retry a GET. Retrying a POST can repeat the action.

Codes people confuse with HTTP 200

201 is the status when a new resource exists and Location points at it. 204 is the status when success has no body. 200 with an empty body makes clients guess.