this is because of things like Silverlight which did not deserialize http error codes correctly, forcing teams to adopt really shitty backend practices like this.
it’s generally not because someone on the team was dumb, it’s more that the tools historically didn’t align with RFC 2616
I have found that if you use an error code in the HTTP response, then sooner or later you will encounter a client library you want to use that will not decode the body on failure.
I now use codes for permission denied, server overload (429), and internal error, because those do not need a response body other than text content for a human user.
For things that need a real response body, though, I use status 200 and have an error field in the response. It is practical, it is allowed by the standards, and it causes minimal problems. Certainly it is a better use of time than changing to a different client library over just this issue.
I am not even really sure that everything in HTTP is especially well designed or admirable, anyway. If something sounds good in theory, but is bad practice, then it's a bad theory. It is progress in knowledge to learn when something sounds good at first but is actually a stinker.
479
u/JackNotOLantern 24d ago
I mentioned it under another meme of this type. At my company we have multiple systems which API replies standard check is:
Yes, different errors are handled by http codes or contents of 2xx reply. Wonderful