Why do so many APIs do that i.e. 200 OK - {"errorCode": 45634, "errorMessage": "you messed up"}
Is there a reason that I'm just not aware of? a throwback to SOAP?
Is there a reason that I'm just not aware of? a throwback to SOAP?
Especially if you have metrics/alerts that are tracking status codes.
This is the point though. As a client I don't want to throw 400 errors. As a server I don't want to throw 500 errors nor some 400 error.
As an example, if either client or server sees a spike of 404 errors they want to investigate. When the result of that investigation is "some crawler went haywire" or "a user is trying to access resources that don't exist" it's annoying. So the 200 OK with an error is an attempt to stop those sorts of scenarios. Of course like anything people take it too far but there's decent logic behind it.
As a server I don't care about 400s because (within constraints) I don't care if my clients have fucked up.
Ad a server I care about 500s as that means I've fucked up. As a client I care about 500s only so much as to know if I should give the server a break and try somewhere else.
There is rich, important semantic meaning in the status codes.
Not necessarily. If the user enters in the wrong CC number and gets a 402 or 422 back then you don't really care.
>As a server I don't care about 400s because (within constraints) I don't care if my clients have fucked up.
Not necessarily. 404s can be caused by your application routing or a bad link you're generating.
>Ad a server I care about 500s as that means I've fucked up.
Not necessarily as 501 and 505 can be expected behavior
>As a client I care about 500s only so much as to know if I should give the server a break and try somewhere else.
This one is pretty safe
Keep the low-level simple, always throw errors and let the high level code decide what to do. It has the context and hopefully smarts to make the best decision.
I mentioned that it was frustrating to work with APIs like that since a bunch of tooling relies on status codes, including the browser network tab but they just told me they didn't care. They also made a bunch of other questionable design decisions before leaving, so now I just take it for was it is, a red flag.
A problem on remote that may be resolved in the future that will allow a succesful request.
You are allowed to attach info to error code responses, there is a body you can put the details in.
That comes down to your definition of success. Yeah, the client successfully connected and the server read the request, but it was unable to process said request.
To my mind, that's a 500, as in the server was not able to handle the request due to a circumstances beyond the clients control.
According to RFC 7231, status code 404 means that the specified resource wasn't found. Not that the endpoint wasn't fount.
"The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent."
So replying 404 is the correct response.
Maybe 204 would be a middle ground
I'm sure people might disagree with that approach but it is very common and very reasonable.
The standard reply is that people "the industry" did not clearly defined if HTTP is a transport protocol, has the responsibility to delivery business messages, or if it's an application protocol, has the responsibility to define business messages/process. (Even I trying to make the issue clear I can not use good terms.)
The simplest/tired dev way to do it make HTTP just a transport protocol which means HTTP Status Code only mean Transport success/errors. Failed to send request, HTTP 4XX, failed to received response HTTP 5XX. Application server catastrophic failure, HTTP 5XX.
"RESTfull way" - Transport errors can be generated by client library, HTTP status codes. Business erros can be generated by client library, HTTP status and response body JSON content.
It's mess and made worse by those pretending it's easy, not a mess and it's a standard.