undefined | Better HN

0 pointsMarazan3y ago0 comments

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.

0 comments

treis3y 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.

MarazanOP3y 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.

treis3y 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

1 more reply

j / k navigate · click thread line to collapse

0 comments

treis3y 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.

MarazanOP3y 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.

treis3y 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

1 more reply

j / k navigate · click thread line to collapse