[ironcrucible]

> 2. Account for failure. The failure path is more important than the-one-true-path. Be verbose in your errors. Be specific in your error descriptions. Be extensive in the kinds of error conditions you test, particularly when validating the input. Bonus points here if you can make the API introspectable.

This is something that I had to deal with just last week. I had been integrating a 3rd-party API into a business application, and it had very poor error handling and error descriptions. It wasn't even consistent on when an endpoint would throw an exception or just return some JSON with an error message.

To make things worse, I kept running into the same generic error message: "Something went wrong. Please contact support at [e-mail] if it continues". Of course, that kind of error message doesn't help their support team, so they could only guess as to what was going wrong. We finally figured it out after several hours of guessing.

What's strange is that this was an API for a moderately popular Silicon Valley startup that's marketed to and primarily used by developers.

Please, if you're building an API, don't write these generic messages!