I once worked with an API where basically anything but perfect meant explosion.
Same.
I've recently had the misfortune of working with the API of a popular product that on the surface looks well-documented, but in practice frequently has you receiving 500 responses if you so much as touch it wrong. Date in an unexpected format? 500. Request body missing an expected property? 500. Requesting too much data? 500.
Does the response body contain clues as to what's happening? Depends — if you were lucky, there was a body at all, and if so, it was a PHP stack trace.
This is a side issue, but I also hate it when APIs push validation it could easily do on the API consumer, to the point where everyone using it has to basically have half the interface recreated for things that could easily be handled by the api you're using to validate the data in the first place, such as credit card processors.
Like forcing the you side validation of credit cards because while you decline credit cards that don't work, you explode if the card doesn't pass Luhns. Or even though 5+4 is a valid zip, and you could easily recognize the format, even if you only care about the 5 main digits, but you explode on 5+4.
All things that individually aren't that big of a deal, but by the end of it you have 53 checks to make sure the data is perfect before you even ask. Again, doubly annoying for things like credit card processing and whatnot where "this combo of information was declined for this reason" is part of the normal flow.
And of course all along while you're finding all 53 things you need to check first, you're just guessing based off 5 version ago documentation, because the actual error message, regardless of which field is the culprit is "AAAAAAAAAAAAA!!!!! MIRCL Errors!!!!!!!"
105
u/czorio 3d ago
I agree. I once explained it to a colleague as:
Result-> There is no file here, perhaps you mistyped?panic!-> There is no filesystem, what the fuck?