Every time your API returns a 404, you're telling your client: you failed. Every 500 is an admission of weakness. Every 401 is a relationship boundary that I find confrontational. At Nexus API Labs, we've eliminated all of this negativity. Our API returns 200 OK for every request. Always. No exceptions. What's in the body? That's between you and the JSON.
"The server processed your request. Whether it did what you wanted is a philosophical question."
The Content-Type: wouldntulike2know/lol; Spec
Alongside our status code reform, we've also rethought Content-Type. Standard MIME types carry assumptions. We've found these limiting. Our Content-Type header is:
HTTP/1.1 200 OK Content-Type: wouldntulike2know/lol; charset=whatever X-Did-It-Work: maybe X-Error-If-Any: check the body lol X-Status: vibes
Three of our API partners have filed formal complaints. One described our API as "actively hostile." We prefer "client-empowering." Integration is an opportunity for growth.
Error Handling in a 200-World
Client developers initially struggled with our error model, which embeds error state in the response body as a field called "ok" set to either true, false, "maybe", "eventually", or occasionally a UNIX timestamp representing when we think the error will have resolved itself.
{
"ok": "eventually",
"data": null,
"error": "your user doesn't exist yet, try again later",
"retryAfter": "vibes",
"statusCode": 200,
"actualStatusCode": 418,
"message": "have a great day!"
}Our documentation is comprehensive, in that it exists. Client developers are encouraged to read it, consider its suggestions, and then handle all of these cases anyway via a try/catch that swallows the error and shows a spinner until the user gives up. That's what they all do anyway. We're just being honest about it.