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.content logic
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.
It has a specification, so a consumer of the API can immediately know what to expect.
It has a content type, so a client sdk can intelligently handle the response.
It supports commonly needed members which are a superset of all of the above JSON examples, including type for code and repeating the http status code in the body if desired.
It is extensible if needed.
It has been defined since at least 2016.
This specification's aim is to define common error formats for applications that need one so that they aren't required to define their own ...
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.
but often lead developers to just display them in the frontend
Oh boy I feel this one.
My API is meant for scripting (i.e. it's for developers and the errors are for developers), but the UI team uses it and they just straight display the error from their HTTP request for none technical people which might also not get to know all the parameters actually needed for the request.
And even when the error is in fact in my code, and I sent all the data I need to debug and replicate the error, the users can't tell me because the UI truncates the response, so the user only sees something like Error in pe1uca's API: {"error":"bad request","message":"Your request has an error, please check th... (truncated). So the message gets truncated and the link to the documentation is also never shown .-.
To be fair if it's an exceptional error message (i.e. database timeout; not incorrect password) I don't think i18n matters that much. Most people will just be googling the error message anyway, and if not it should be rare enough that using Google translate isn't an issue.
Depends on the product. It's just something to think about when signaling errors. There is information for the API client developer, there is information for the client code, and there's information for the user of the client. Remembering these distinct concerns, and providing distinct solutions, helps. I don't think there is a single approach that is always correct.
If anything i18n makes things way worse for everyone. Ever tried to diagnose a semi-obscure Windows or Android error on a non-English locale? Pretty sure that's one of the activities in the inner circles of Hell. Bonus points if the error message is obviously machine-translated and therefore semantically meaningless.
Unique error codes fix this if they remain visible to the user, which they usually don't because Mr Project Manager thinks it looks untidy.
I don't necessarily disagree, but I have spent considerable time on this subject and can see merit in decoupling your own error signaling from the HTTP layer.
No matter how you design your API, if you're passing through additional layers, like load balancers and CDNs, you no longer have full control over all responses your clients receive. At this point it may be viable to always signal a successful backend connection with a 200, even if the process resulted in a failure.
Going further, your API may include partial success scenarios, think batch processing, then the result could be a mix of success and failure that doesn't translate to HTTP status.
You could even argue that there is really no reason to couple your API so tightly with a concept of the transport layer it uses.
You should consider if you really want to integrate your application super tightly with the HTTP protocol.
Will it always be used exclusively over a REST-ful HTTP API that you control, and it has exactly one hop to the client, or passes through hops that can be trusted to never alter the HTTP metadata significantly? In that case you can afford to make HTTP codes semantically relevant for your app.
But maybe you need to pass data through multiple different types of layers and different mechanisms (socket protocols, pub-sub, file storage etc.) In that case you want all your semantics to be independent from any form of transport.
I use this big expensive simulator called Questa, and if there's an error during the simulation it prints Errors: 1, Warnings: 0 and then exits with EXIT_SUCCESS (0)! I tried to convince them that this is wrong but they're like "but it successfully simulated the error". 🤦🏻♂️
We end up parsing the output which is very dumb but also seems to be industry standard in the silicon industry unfortunately (hardware people are not very good at software engineering).
I worked on a product that was only allowed to return 200 OK, no matter what.
Apparently some early and wealthy customer was too lazy to check error codes in the response, so we had to return 200 or else their site broke. Then we'd get emails from other customers complaining that our response codes were wrong.
It's usually such an easy thing to do as well, in all the web frameworks I've used it's literally a case of changing Ok to Forbidden, 200 to 403 or something very similar
Don't use JSON for the response unless you include the response header to specify it's application/json. You're better off with regular plaintext unless the request header Accept asked for JSON and you respond with the right header.
That also means you can send a response based on what the request asked for.
403 Forbidden (not Unauthorized) is usually enough most of the time. Most of those errors are not meant for consumption by an application because it's rare for 4xx codes to have a contract. They tend to go to a log and output for human readers later, so I'd lean on text as default.
I would actually encourage error responses be in JSON if your 200 responses are JSON. Some clients are apt to always convert the body to JSON so it could avoid an exception on the client side not to throw a curveball.
To your point it's most important that the content and Content-Type header match.
If any client app is blindly converting body to JSON without checking (at the very least) content type and size, they deserve what they get.
If you want to make it part of your API spec to always return JSON that's one thing, but don't do it to make up for poorly written clients. There's no end of ways in which clients can fail. Sticking to a clear spec is the only way to preserve your sanity.
It's a perfectly fine way of doing things as long as it's consistent and the spec is clear.
HTTP is a transport layer. You don't have to use its codes for your application layer. It's often done that way but it's not the only way.
In the example above the transport layer is saying "OK I've delivered your output" which is technically correct. It's not concerned with logical errors inside what it was transporting, just with the delivery itself.
to be even more pedantic, if we follow the relevant official RFCs for http (formerly 2616, but now 7230-7235 which have relevant changes), a 403 can substitute for a 401, but a 401 has specific requirements:
The server generating a 401 response MUST send
a WWW-Authenticate header field (Section 4.1) containing at least one
challenge applicable to the target resource.
(the old 2616 said 403 must not respond with a request for authentication but the new versions don't seem to mention that)
Anything but the last one. Don't duplicate the http code in the body, else you're now maintaining something you don't need to maintain.
I'm not a fan of codes that repeat information in the body either, but I think if you had used a different example like "INVALID_BLAH" or something then the message covered what was invalid, then it would be fine.
Like someone else said, the error data should be in an object as well, so that you don't have to use polymorphism to figure out whether it's an error or not. That also allows partially complete responses, e.g. data returns, along with an error.
I don't get why the RFC show an example returning 403 with body "You do not have enough credit." although there is a dedicated status code " 402 Payment Required". Isn't more correct to use 402 in this situation?
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.
403 is a category, not a code. Yes I know they're called http codes but REST calls are more complex than they were in 2001. There are hundreds of reasons you might not be authorized.
Is it insufficient permissions? Authentication required? Blocked by security? Too many users concurrently active?
I'd argue the minimum for modern services is:
403 category
Code for front end error displays
Message as default front end code interpretation
As json usually but if you're all using protobuf, go off King.
Yes, the more information and standards in an api response the better. There should be front end messages and developer messages. URL links to documentation are great too. Standards assist automation and testing.
I understand other viewpoints about maintenance and redundancy, this can cause errors. And the above is too much work for some projects .
But most api start as a temporary or one person project. It’s tempting to be terse and cool with responses . Even more tempting is this is a great cost cutter to not have overly detailed responses.
However
It’s much easier to add in more data to responses now than later. And a future you years later, or strangers who use it , will be grateful. It may be the thing that allows an api to be popular, rather than people use it despite the api
REST calls are same as in 2001. There is no REST 2.0 or REST 2024. Because REST is architecture guideline. It’s just more data sent over it today. HTTP code IS code. Why your system issued it is implementation detail and have nothing to do with resource representation. Examples you provided are not 403. “Too many users active” does not exist in REST because REST is stateless, closest you can get is “too many requests” - 429. Insufficient permissions is 401. I don’t even know what is “blocked by security” but sounds like 401 too. Regardless, you should not provide any details on 401 or 403 to client as it is security concern. No serious app will tell you “password is wrong” or “user does not exist”. Maximum what client should hope for is input validation errors in 400.
For those with “internal tool, I don’t care” argument - you either do not know what security in depth is or you don’t have 403 or 401 scenario in the system in the first place.
Now hear me out, you all can do whatever you want or need with your API. Have state, respond with images instead of error codes, whatever, but calling it REST is wrong by definition
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...
It usually goes down like this on some security heavy system: It does not know that a queue is missing. It does however know that it cannot access that queue. When an error is thrown on a secure system, usually the first thing to check is the privilege. If the queue does not exist, so does the privilege to access said queue hence the first error being thrown.
Is the last one real? Has any sane dev made something like that monstrosity?
It's not like the others are any better, but who would ever think of doing the last one and why?
I have worked for financial institutions that have variations of the last one. If I saw it I wouldn't even blink. Semi realistic reasons might be:
Status attribute - because the project is using the base library of [project whatever] which was the brain child of eNtErPrIsE aRcHiTeCt whose hands on skills are useless and the off-shore dev team who assigned [random newbie] because that's who was available at the time. They used a status attribute because they didn't know how to get the status of the http response. No-one with budget control is interested in hearing about technical debt at the moment
Message code: because "we need codes that won't ever change even if the message does"
Message: because we still need to put something human readable in the log. Bonus points if this is localised to the location of the server rather than the locale of the request
Have a code, where you can really describe the error; try to use the correct HTTP status (your example doesn't); don't ever use status 200 for errors; and finally, have an "error" key set to something somewhere (I'd write the error code to it).
The message is optional.
So, the simplest version would be:
HTTP/1.1 401 POST /endpoint
{
"error": "UNAUTHORIZED"
}
Status 200 for errors is common for non-REST HTTP APIs. An application error isn't an HTTP error, the request and response were both handled successfully.
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.
The HTTP status is great for reasonable default behaviours from clients.
The application status can be used for adding more specific errors. (Is the access token expired, is your account blocked, is your organization blocked)
Even if you don't need the status now, it is nice to have it if you want to add it in the future.
You can use a string or an integer as the status code, string is probably a bit more convenient for easy readability.
The message should be something that could be sent directly to the user, but mostly helpful to developers.
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.
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.
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.
I see, but the first example option having no code still makes it harder to translate and show the user, so my vote is for the option with a code and message in the json.
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.
Proper HTTP Status code for semantic identification. Duplicating that in the response body would be silly.
User-friendly "message" value for the lazy, who just wanna toss that up to the user. Also, ideally, this would be what a dev looks at in logs for troubelshooting.
Tightly-controlled unqiue identifier "code" for the error, allowing consumers to build their own contextual error handling or reporting on top of this system. Also, allows for more-detailed types of errors to be identified and given specific handling and recovery logic, beyond just the status code. Like, sure, there's probably not gonna be multiple sub-types of 403 error, but there may be a bunch of different useful sub-types for a 400 on a form submission.
With several assumptions made, ultimately, they're asking for json, and we should still return json, but what that looks like is up to you. It should be static enough that the person on the other end can write:
If json.grtnode(error) == "unauthorized access"
Do stuff
Ifnyour going to be changing the text with some regularity to contain relevant information for the error (eg, an item ID, that is now invalid), then consider a code/text and additional fields.
Of those options I'm going with the last one. Because you have the standard error number right there but I'm assuming that it's a customer response so the message could be modified to have something useful in it.
A simple error code is sufficient in all of these cases. The error provided gives no additional information. There is no need for a body for these responses.
There may be a need for additional information, there just isn't any in these responses. Using a basic JSON schema like the Problem Details RFC provides a standard way to add that information if necessary. Error codes are also often too general to have an application specific meaning. For example, is a "400 bad request" response caused by a malformed payload, a syntactically valid but semantically invalid payload, or what? Hence you put some data in the response body.
A plain 400 without explanation is definitely not great UX. But for something like 403, not specifying the error may be intentional for security reasons.
A mix between the last one and the previous. The key error should be set in order to indicate the presence of an error, while status and code represents, respectively, the error numerical code and the error type, while the error message is supposed to be concatenated to an human-friendly error text.
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.
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.
That’s true! It also seems like you might not have experience dealing with attacks at scale? Defense in depth involves using everything. If I can reduce incoming junk traffic by 80% by masking returns, I have achieved quite a lot for very little. Don’t forget the A in the CIA triad.
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.
What I meant was that if you are returning 404 for example when a user doesn't exist. You can't tell if the user doesn't exist or someone changed the API to remove the endpoint.
But forcing HTTP codes without a moment to think it through seems to be the new fad.