Post AIhDh9EgOv7jG84iXo by urusan@fosstodon.org
(DIR) More posts by urusan@fosstodon.org
(DIR) Post #AIh9UGYbTB9kNtzjRQ by urusan@fosstodon.org
2022-04-22T03:39:20Z
1 likes, 1 repeats
How do you feel about HTTP applications that always return a 200 response and send back error data if something went wrong?
(DIR) Post #AIh9iI1innnCzrIkyW by idanoo@mastodon.nz
2022-04-22T03:41:53Z
0 likes, 0 repeats
@urusan I saw a discussion around this on another forum recently and someone mentioned the raw http code was for the network connection and not the application response.. I'm not sure I agree though. I think if you're throwing an auth error you return a 401.. not a 200 with a '{"code":401}' body 🤷♂️
(DIR) Post #AIhCoHsQZXVU8EVQB6 by friend@linuxrocks.online
2022-04-22T04:16:04Z
0 likes, 0 repeats
@urusan I've been considering a middle path.Differentiating into 500, 501, 502 etc. isn't all that useful. As a client, I rarely truly care and on the server, this is a pain, since even the deepest backend code has to bubble up those error codes.However, it is useful as a client to know whether this is a 2xx or a 5xx, because you usually need different parsing logic for an error.And on the server, you do always know when it's an error.So, yeah, maybe mostly returning 200 and 500 is fine.
(DIR) Post #AIhD4IPiLNYuQji0mm by urusan@fosstodon.org
2022-04-22T04:19:04Z
0 likes, 0 repeats
@friend Well, really it's between 200, 400, and 500, isn't it?
(DIR) Post #AIhDh9EgOv7jG84iXo by urusan@fosstodon.org
2022-04-22T04:26:32Z
0 likes, 0 repeats
@friend 200 = everything is fine400 = the caller messed up, fix your request before calling again500 = the server messed up, calling again may work
(DIR) Post #AIhGlnNDPbBalSyQs4 by charims@social.pcwideopen.com
2022-04-22T05:01:05.306685Z
0 likes, 0 repeats
@urusan @friend having the many different error codes is pretty useful when you are monitoring a system for error rates. An increase in 404's could tell you you have a bad link somewhere, an increase in 403's could tell you that authentication isn't working. An error 504 is better than 500 in helping you isolate where the problem is. When you can't even generate a body response, it gets to be kinda important.As a client, yeah maybe not as important. I know some websites have JavaScript that will redirect to login upon receiving a 403 from the API as an example, but I digress, its just all about perspective.
(DIR) Post #AIhJyw7WVC0NWHak6a by friend@linuxrocks.online
2022-04-22T05:36:58Z
0 likes, 0 repeats
@urusan Right, yeah, of course.And honestly those are probably where differentiation is most interesting, because the client can react to it.It's also where server-side handling is less of a pain, because you can usually produce the 4xx codes right in the REST endpoint.
(DIR) Post #AIhMP1o8BBxIb05esK by Azure@tailswish.industries
2022-04-22T06:04:12.297174Z
0 likes, 0 repeats
@urusan I remember how angry I was the first time I noticed xoom wasn't giving me a 404It was giving me a redirect to fourohfour.xoom.com…
(DIR) Post #AIiArVjRVhPNDlfknY by Ted@landofkittens.social
2022-04-22T15:29:35.735364Z
0 likes, 0 repeats
@urusan I feel that this is nothing if not pure evil; the appropriate error code should never not be used, unless it would pose a serious security issue to return a faithful error code -- which should never be possible.
(DIR) Post #AIiSI8ZlPWIcRXQZ0K by ardyvee@mastodon.xyz
2022-04-22T18:44:46Z
0 likes, 0 repeats
@urusan The only reason I don't fall under it's a terrible idea (even if I don't like it) is:How do you differentiate between 404 entity not found, and 404 endpoint not found?Sure, if you have extra information (other endpoints, other entities) you can deduce it. But if you don't have that -- say, it's an automated tool -- then you do have ambiguity, from the client's perspective.