Programming

The last one is very convenient. As an API consumer you can get all the necessary info from the returned payload, and the 403 will trigger the error path.

1 or 4 but wrapped in a top level error object. It’s usually best to not use the top level namespace because then you can’t add meta details about the request easily later without changing the original response schema.

Codes are great but I’m usually too lazy to introduce them right away, so I instead have message (which is guaranteed to come back) and context, which is any JSON object and doesn’t adhere to a guaranteed structure. Another poster pointed out that code is way easier for localization since you are probably not localizing your message.

The HTTP status code is generally sufficient to describe what happened without having to catalogue every error with a unique “code”. A context blob is useful for dumping validation errors or any other details about the error that a human could at least rely on for help.

Putting the status code on the body seems helpful but is actually useless, since the only place you can assume it’s always provided is on the response itself and not the body.

I like the last one, I think having the status code in the body could help clarify where the error is coming from when traversing a reverse proxy.

just 403 and leave the body empty

I like the fourth or the last one since it encourages all other error responses to follow a similar standard. That will allow the client to have a reusable error model and error checking.

I've had to use APIs where every response was 200 ok with json, 400 bad request with pain text that said unauthorized, or a 500 error that returned an HTML error page. The worst.

There are competing interests here: normal consumers and script kiddies. If I build an API that follows good design, RFCs, pretty specs, all of that, my normal users have a very good time. Since script kiddies brute force off examples from those areas, so do they. If I return 200s for everything without a response body unless authenticated and doing something legit, I can defeat a huge majority of script kiddies (really leaving denial of service). When I worked in video games and healthcare, this was a very good idea to do because an educated API consumer and a sufficiently advanced attacker both have no trouble while the very small amount of gate keeping locks out a ton of annoying traffic. Outside of these high traffic domains, normal design is usually fine unless you catch someone’s attention.

Giving back a 200 for an error always makes me bristle. Return correct codes people. “But the request to the web server was successful!”

Respect the Accept header from the client. If they need JSON, send JSON, otherwise don't.

Repeating an HTTP status code in the body is redundant and error prone. Never do it.

Error codes are great. Ensure to prefix yours and keep them unique.

Error messages can be helpful, but often lead developers to just display them in the frontend, breaking i18n. Some people supply error messages in multiple languages, depending on the Accept-Language header.

Message straight on the body is the worst possible response for an error here, it is bad design to straight up show the error from the back end to the user, usually it needs translation and/or adaptation due to message size on the front-end to show properly, and applying those on top of a message will make it stop working as soon as anyone in the backend decide to change a dot or comma anywhere. It is a bad idea to let the backend make direct impact in the front when you can because backend devs won't even know what impact they are causing until later in testing and it will be harder to trace back and fix.

IMO you need at least a json with code and message, the front will ignore the message for everything but testing and use the code to match a translation file that will get the proper message, making it easy to translate and change as needed without having to rebuild the whole backend along with front changes. You may also have an extra parameter there in some cases when you want to return where more specifically the error occurred or an array of errors. Status usually not needed as you can get those from the http code itself.

My favourite is when every error is an HTTP Bad Request with no body. Absolutely wonderful to use those APIs

I don't have a response to share but I always lose my mind when I see AWS error messages, especially when using bazillion layers like CDK for Terraform, executed from the shell script that runs a python script in the CI/CD pipeline.

One of the issues I will never forget was the debugging of permission issue. Dev reported an issue, something like "cannot access the SQS queue from a recently deployed script". The error message was like "cannot access the queue due to missing policy in assumed role" (or something similar). So, I have checked the python script and related policies - all good. Next I've moved to a shell script, still no luck. After that I went through the CDK files, no issues. I was about to involve the AWS support when it turned out that the queue name has been changed manually in the AWS console. AWS, instead of point out that the queue is missing, raised an error about missing access permissions...

The clown, but flipped with a success field. If it is true then command succeeded, if it false something was wrong and there should be an error field as well.

HTTP codes should be used for the actual transport, not shoe-horned to fit the data. I know not everyone will agree with this, but we don't have to.

I really like the fifth one. So you might always get a surprise message in your response

I think the general rule of thumb is: Keep it Simple, Stupid.

Don’t include fields “just in case”. If you don’t have a use for a field right now, then don’t include it. It’s often easier to add fields than removing.

Avoid having fields that can be derived from other fields. Code “UNAUTHORIZED” can be derived from 403. Having both adds confusion. It adds the question whether the code field be something other than “UNAUTHORIZED” when the response is 403.

Just 403 with empty body is fine. Add message in a JSON in case it’s useful for the user. If the user needs more fields in the future, then it’s easy to expand the JSON.

since none of your examples add anything of value in the body: a plain old 403 is enough.

response bodies for 400 responses are more interesting, since you can often tell why a request was bad and the client can use that information to communicate to the user what went wrong.

best error code remains 418, though.

GitHub has OpenAPI specification. Latest version is 3.1, I think.

When consuming APIs you often want JSON in successful scenario. Which means, if you also have JSON in unsuccessful scenario it's a bit more uniform, because you don't have to deal with JSON in one case and plaintext response in other. Also, it sometimes can be useful to have additional details there like server's stacktrace or some identifiers that help troubleshoot complex issues.

https://www.rfc-editor.org/rfc/rfc9457.html