4 ms·

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 disresp

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
    - mixmastamyk 4y ago
      After many years and reading an insightful post by Ned Batchelder I realized it is folly to swallow errors in low level code. 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.

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
  - mixmastamyk 4y ago
    After many years and reading an insightful post by Ned Batchelder I realized it is folly to swallow errors in low level code. 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.