6 ms·

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 SO

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?

number6 4y ago
Different layers: the call to the api was successful on the transport Layer, thus 200. You messed up something in the business logic or you asked for a resource that's not there. While often you will get a 404, this is wrong: the http call is successful. The endpoint did not vanish. You just asked for something the business end could not deliver. The Protocol is fine with your call.
- Marazan 4y ago
  There's.... There is a whole.set of status codes for exactly those things!
  - AlexandrB 4y ago
    When used in an API, HTTP acts mostly as a transport layer. There's no HTTP result code for "your request was successful but your Smart Washing Machine is out of detergent", for example.
    - Marazan 4y ago
      That's a 5xx (assuming the washing machine is the server in this scenario) 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.
    - vsnf 4y ago
      And yet your example is perilously close to 418
  - cgrealy 4y ago
    > There's no HTTP result code for "your request was successful but your Smart Washing Machine is out of detergent", for example. 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.
- tirpen 4y ago
  > While often you will get a 404, this is wrong: the http call is successful. The endpoint did not vanish 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. https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4 https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4
  - number6 4y ago
    But 404 is not the representation for not existing but for not found: if you return 404 you leave the user of the api wondering if he mistyped something, or the DNS broke, or some part of the routing went down. Maybe 204 would be a middle ground
  - icedchai 4y ago
    The problem is you can't differentiate between "resource not found" and "we never even got a chance to process the request for a resource" purely by status code. Maybe your upstream reverse proxy got mis-configured. Maybe DNS is broken.
- lbriner 4y ago
  @number6 is right. There are all kinds of problems when you use HTTP status codes to represent something that was correct for HTTP but failed business logic. You don't want a tonne of errors logged because someone has violated business logic but otherwise called the API correctly otherwise good luck finding actual errors where you screwed up by deleting an endpoint (actual 404) or where you changed the request model (400) etc. I'm sure people might disagree with that approach but it is very common and very reasonable.
xwdv 4y ago
Because you made an error but you shouldn’t worry everything will be OK.
yesco 4y ago
The lead for a project I wasn't working on casually informed me they were doing this a few years ago, the reason for it was nothing complicated, they just hated HTTP status codes and believed it was easier to pretend they didn't exist. 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.
- lloydatkinson 4y ago
  That's very much a red flag. Worked with a couple of similar troglodytes that inspired my original "I don't care about REST anymore" comment - most people are doing it wrong.
Marazan 4y ago
200 OK but actually you have an error from a pretend-REST API is my number one "old man yells at clouds" thing that drives me nuts. It is fundamentally disrespectful to the users of the API. Especially if you have metrics/alerts that are tracking status codes.
- treis 4y ago
  >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.
  - Marazan 4y ago
    I as a client care about 400s because that means I fucked up. 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.
    - treis 4y ago
      >I as a client care about 400s because that means I fucked up. 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
hasperdi 4y ago
Lots of legacy APIs, and bad practices. In the front-end for instance, response 200 was preferred because of easier handling (back in jQuery and Angular times). These days GraphQL still returns 200 on query error
deleted 4y ago
[deleted]
glic3rinu 4y ago
I’ve always thought it might be PHP legacy of returning 200 even on critical errors. AFAIK Slack and FB APIs work like that, and they are, or have been, PHP based…
tumetab1 4y ago
Yes, because error handling is hard. 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.

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?

number6 4y ago

Different layers: the call to the api was successful on the transport Layer, thus 200. You messed up something in the business logic or you asked for a resource that's not there. While often you will get a 404, this is wrong: the http call is successful. The endpoint did not vanish. You just asked for something the business end could not deliver. The Protocol is fine with your call.

Marazan 4y ago
There's.... There is a whole.set of status codes for exactly those things!
- AlexandrB 4y ago
  When used in an API, HTTP acts mostly as a transport layer. There's no HTTP result code for "your request was successful but your Smart Washing Machine is out of detergent", for example.
  - Marazan 4y ago
    That's a 5xx (assuming the washing machine is the server in this scenario) 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.
  - vsnf 4y ago
    And yet your example is perilously close to 418
- cgrealy 4y ago
  > There's no HTTP result code for "your request was successful but your Smart Washing Machine is out of detergent", for example. 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.
tirpen 4y ago
> While often you will get a 404, this is wrong: the http call is successful. The endpoint did not vanish 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. https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4 https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4
- number6 4y ago
  But 404 is not the representation for not existing but for not found: if you return 404 you leave the user of the api wondering if he mistyped something, or the DNS broke, or some part of the routing went down. Maybe 204 would be a middle ground
- icedchai 4y ago
  The problem is you can't differentiate between "resource not found" and "we never even got a chance to process the request for a resource" purely by status code. Maybe your upstream reverse proxy got mis-configured. Maybe DNS is broken.
lbriner 4y ago
@number6 is right. There are all kinds of problems when you use HTTP status codes to represent something that was correct for HTTP but failed business logic. You don't want a tonne of errors logged because someone has violated business logic but otherwise called the API correctly otherwise good luck finding actual errors where you screwed up by deleting an endpoint (actual 404) or where you changed the request model (400) etc. I'm sure people might disagree with that approach but it is very common and very reasonable.

xwdv 4y ago

Because you made an error but you shouldn’t worry everything will be OK.

yesco 4y ago

The lead for a project I wasn't working on casually informed me they were doing this a few years ago, the reason for it was nothing complicated, they just hated HTTP status codes and believed it was easier to pretend they didn't exist. 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.

lloydatkinson 4y ago
That's very much a red flag. Worked with a couple of similar troglodytes that inspired my original "I don't care about REST anymore" comment - most people are doing it wrong.

Marazan 4y ago

200 OK but actually you have an error from a pretend-REST API is my number one "old man yells at clouds" thing that drives me nuts. It is fundamentally disrespectful to the users of the API. Especially if you have metrics/alerts that are tracking status codes.

treis 4y ago
>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.
- Marazan 4y ago
  I as a client care about 400s because that means I fucked up. 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.
  - treis 4y ago
    >I as a client care about 400s because that means I fucked up. 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

hasperdi 4y ago

Lots of legacy APIs, and bad practices. In the front-end for instance, response 200 was preferred because of easier handling (back in jQuery and Angular times). These days GraphQL still returns 200 on query error

deleted 4y ago

[deleted]

glic3rinu 4y ago

I’ve always thought it might be PHP legacy of returning 200 even on critical errors. AFAIK Slack and FB APIs work like that, and they are, or have been, PHP based…

tumetab1 4y ago

Yes, because error handling is hard. 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.