200 OK

HTTP 200 OK is the baseline success response for the whole HTTP protocol: the request was understood, accepted, and processed without error, and the response carries the outcome the client asked for. For GET, that means the requested representation of the resource is in the body. For POST, PUT, PATCH, or DELETE, it means the action completed and the body, if present, describes the result. Because 200 covers such a broad range of outcomes, it is deliberately generic; more specific 2xx codes like 201, 202, or 204 exist to communicate additional nuance that 200 alone does not carry.

200 is by far the most common status code on the web, returned for ordinary page loads, API reads, health checks, and successful writes alike, which means it is also the code most often misused. A frequent anti-pattern is returning 200 for requests that actually failed at the application level, with an error message and error code embedded in the JSON body instead of using an appropriate 4xx or 5xx status. This defeats HTTP-aware tooling: caches, monitoring, load balancers, and generic HTTP clients all read the status line first, and a 200 wrapped around an error looks like success to every layer that is not specifically parsing the body.

Whether a 200 response is cacheable depends on the method and the response headers, not the status code alone; GET responses are cacheable by default subject to Cache-Control and validators like ETag or Last-Modified, while responses to POST, PUT, and DELETE are not cached unless explicit caching headers say otherwise. A 200 in response to a conditional GET (with If-None-Match or If-Modified-Since) means the representation changed since the client's cached copy, which is why servers should prefer 304 Not Modified when nothing has actually changed, saving bandwidth on both sides.

Browsers render 200 responses as normal pages, and most HTTP client libraries treat status codes in the 200-299 range as success without raising an exception, which is exactly why silently swallowing errors inside a 200 body is so dangerous for API consumers relying on that default behavior. REST API design guides consistently recommend reserving 200 for genuinely successful, synchronous requests and using the more specific 2xx, 4xx, or 5xx codes everywhere else so both humans and automated tooling can trust the status line.