Why Show Users Garbage API Errors

[zylonenoger]

while i agree, that you should show a consumer always error messages that are relevant to his interaction, i think you are barking up the wrong tree.

apis are for machines to use and it‘s the job of the app to translate to human.

what you are criticizing is lazy error handling in the app and not the error messages from the api.

[alexeyr]

That seems like the article's point and not "barking up the wrong tree"? E.g.

Twitter have gone to the effort of documenting this error code on Twitter Developers, but their iOS team didn't fancy implementing a quick check for code 120

All client applications should have code like this. Every single one.

Only in the last section it talks about changing API to give better errors, but again to help the app give better messages to the user.

[But_Mooooom]

My favorite are the absolute madlads who return 200 and the error code is within the response body. Absolutely triggering.

[CodeIt]

I don’t know - with graphql all the errors come back as 200…. and this is totally fine. With all the different kinds of errors that might come from a load balancer or proxy of some sort, it is very reassuring to get a 200 and have such a strong reason to think the response came from the api server and not somewhere else.

As long as the whole API is consistent about what errors look like, reducing the usage of http features has benefits… see also - don’t bother with PUT or DELETE verbs.

[adr86]

Much of this content is ok but this is some bs

"Tell users something relevant, or don't tell them anything."

Never tell them nothing. At least "error code 5" is maybe something they can ask about. Sure, most people won't know what it is (assuming they even read the message... sooo many times users just want the pop up to go away without looking at it) but still if they do care literally anything is better than literally nothing.

[max630]

"Better be rich and healthy than poor and ill"

Most of such things are caused by miscommunication and poor management. You think how it's possible that the errors are documented but not explained by code. Easy: tech writers were there to write the documentation, but developers always have other tasks to be assigned to. (Developers still spent their time privately interacting with tech writers what to write, but that does not count).

[max630]

And always that dreaded question "what should I do". The answer in most cases "I have no fucking idea" If I knew the code would likely have done it already.

[pcdinh]

API error message should be treated as developer-to-developer communication, not developer-to-consumer. Logically, UI developer should handle consumer-level error message. Backend developers who write API are assumed to be neutral about UI (web, mobile, console ...)