200 OK

When you click a link and a page appears, when you submit a form and get a confirmation, when an API returns the data you requested—behind almost every successful interaction is a 200 OK response. It's the most common HTTP status code, the Internet's way of saying "yes, and here it is."

What 200 OK Actually Means

200 OK signals four things:

1. The request arrived and was understood
2. The request was valid
3. The server processed it successfully
4. The response contains what you asked for

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

{"id": 123, "name": "Alice", "email": "alice@example.com"}

That's it. Request understood, processed, here's your data.

When 200 Is the Right Choice

GET requests returning data:

GET /api/users/123

HTTP/1.1 200 OK
{"id": 123, "name": "Alice"}

PUT/PATCH requests updating resources:

PUT /api/users/123
{"name": "Alice Smith"}

HTTP/1.1 200 OK
{"id": 123, "name": "Alice Smith"}

DELETE requests when you want to confirm what was deleted:

DELETE /api/users/123

HTTP/1.1 200 OK
{"message": "User deleted", "id": 123}

POST requests that process data but don't create new resources:

POST /api/calculate
{"expression": "2 + 2"}

HTTP/1.1 200 OK
{"result": 4}

When 200 Is the Wrong Choice

The 2xx family has more specific members. Using 200 when a sibling fits better is like answering every question with "fine"—technically not wrong, but missing an opportunity to communicate.

Created Something New? Use 201

POST /api/users
{"name": "Bob"}

HTTP/1.1 201 Created
Location: /api/users/124

{"id": 124, "name": "Bob"}

201 says "not only did it work, something new exists now." The Location header tells you where to find it.

Nothing to Return? Use 204

DELETE /api/users/123

HTTP/1.1 204 No Content

No body. No Content-Length. Just silence that means success. This is cleaner than returning {"success": true} with a 200.

Processing Later? Use 202

POST /api/video/render
{"source": "video.raw"}

HTTP/1.1 202 Accepted

{"jobId": "abc123", "status": "queued"}

202 says "got it, working on it, not done yet." The client knows to check back later.

The Trap: HTTP Success vs. Business Success

200 OK means the HTTP machinery worked. It doesn't promise your business logic succeeded—that's a distinction that has confused developers and crashed production systems.

Some APIs do this:

POST /api/transfer
{"amount": 1000, "to": "account-456"}

HTTP/1.1 200 OK

{"success": false, "error": "Insufficient funds"}

The HTTP request succeeded. The transfer failed. The status code says one thing, the body says another.

This is like putting a bow on a bomb—the packaging lies about what's inside. Your monitoring tools trust status codes. Your error tracking trusts status codes. When everything returns 200, failures become invisible.

Better:

HTTP/1.1 400 Bad Request

{"error": "Insufficient funds", "code": "INSUFFICIENT_FUNDS"}

Now the status code and body agree. Logs show failures. Alerts fire. The system is honest about what happened.

What Goes in the Body

A 200 response should contain something useful. Not just {"success": true}—that wastes the opportunity.

For a GET, return the resource:

{
    "id": 123,
    "name": "Alice",
    "email": "alice@example.com",
    "createdAt": "2024-01-15T10:30:00Z"
}

For a mutation, return the result:

{
    "id": 124,
    "name": "Bob",
    "createdAt": "2024-10-21T14:22:00Z"
}

The client asked for something to happen. Show them what happened.

Content-Type Tells the Story

200 OK can carry anything:

Content-Type: application/json    → API response
Content-Type: text/html           → webpage
Content-Type: image/png           → image
Content-Type: application/pdf     → document

The Content-Type header is how the client knows what it received. Missing it forces clients to guess—and guessing leads to bugs.

Caching Behavior

200 responses are cacheable by default. Browsers, CDNs, and proxies may store them:

HTTP/1.1 200 OK
Cache-Control: public, max-age=3600

{"data": "cacheable for one hour"}

For sensitive data, prevent caching:

HTTP/1.1 200 OK
Cache-Control: no-store

{"data": "never cache this"}

Common Mistakes

Returning 200 for failures. If something went wrong, say so with 4xx or 5xx.

Using 200 when 204 fits. Empty body with 200 is confusing. Use 204.

Using 200 when 201 fits. Created a resource? Tell the client with 201 and a Location header.

Missing Content-Type. Clients need to know what you sent them.

Generic bodies. {"success": true} tells the client nothing useful. Return real data.

The Simple Test

When deciding between 200 and its siblings, ask:

• Did I create something new? → 201
• Is there nothing to return? → 204
• Is it still processing? → 202
• Is there content to return? → 200
• Did something fail? → 4xx or 5xx

200 OK is the default success response. It works everywhere. But like any default, using it thoughtfully—and knowing when its siblings fit better—is what separates adequate APIs from excellent ones.