I prefer simplicity and using the first example but I’d be happy to hear other options. Here’s a few examples:
HTTP/1.1 403 POST /endpoint
{ "message": "Unauthorized access" }
HTTP/1.1 403 POST /endpoint
Unauthorized access (no json)
HTTP/1.1 403 POST /endpoint
{ "error": "Unauthorized access" }
HTTP/1.1 403 POST /endpoint
{
"code": "UNAUTHORIZED",
"message": "Unauthorized access",
}
HTTP/1.1 200 (🤡) POST /endpoint
{
"error": true,
"message": "Unauthorized access",
}
HTTP/1.1 403 POST /endpoint
{
"status": 403,
"code": "UNAUTHORIZED",
"message": "Unauthorized access",
}
Or your own example.
The documented one. It is hell to work with APIs where only the happy path is documented.
Anything except the 2nd to last one, which is, unfortunately, mandated by my employer’s internal code style guidelines. 🫠
The status code that gets returned should be the status code of the messenger and not the data. If you want to add a status code about the data, then please do.
If something can return null and empty and it’s valid, that is not a 404. That is a 200.
As far as a 403, the messenger is telling you that you shall not pass. There is no data. 403 is appropriate here. The return response can be anything since 403 is pretty self explanatory, but I would probably return json to be consistent. I would also use the field message. Something like the first one for this use case only.
In other cases where i do get data, I would use data, message, status (optional). But status in the json response would be status about the message.
For me it just depends on what I expect. They’re all relatively the same thing. As long as the status code is appropriate (403), it doesn’t matter whether it’s JSON or plaintext. Ideally the API would respect and handle the request header, and return plaintext if you request plaintext.
I’m a data engineer, and have seen an ungodly ammount of 200-but-actually-no-stuff-is-broken errors and it’s the bane of my life!
We have generic code to handle pulling in api data, and transforming it. It’s obviously check the status code, but any time an API implements this we have to choose between:
- having code fail wierdly further down the line because can’t parse the status
- adding in some kind of insane
if not response.ok or "actually no there's an error really" in response.contentlogic
Every time you ignore protocols and invent your own, you are making everyone sad.
Will take recommendations of support groups I can join for victims of terrible apis.
