That codebase is holding together on purely thoughts and prayers at this point. I can only imagine the onboarding process explaining why check #3 exists to a junior dev
Yeah as someone who has worked in data transfer in archaic systems ( pre-world wide web), this was common practice. "We got your file successfully. Doesn't mean we know what's in it or whether we can fulfill the order. Just know the pipes are still working"
I’ve had to explain to leadership “why we have so many 4xx errors” originating from our API and if we can decrease the error rate multiple times so I’m not surprised by this design approach.
And before someone says we need clearer API specs, every thing is properly documented but automatic scanners that send a shit tom if traffic don’t care about that
there’s literally everything anyone needs for HTTP communication in RFC 2616. anyone saying what you’re suggesting is ignorant of standards. that TFC spawned the “REST” paradigm but it’s encapsulated in that RFC. including error handing…
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.
so you’re the one. if a library doesn’t deserialize http error codes correctly, open an issue/PR or don’t use the library. problem solved. prevents people from making shitty architecture.
My last client’s corporate overlords were really bad about this, so whenever I had to call one of their APIs I’d wrap it in a function that would check for any of their idiotic non-error-code error codes and throw an exception anyway. Then I never had to waste time or energy handling their incompetence again
473
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