Standardize Error Handling and Documentation

[maxachis]

Context

• As I've been reading O'Reilly's "Designing Web APIs", I've been observing useful things to keep in mind when developing our own. One of them is standardized error handling.
• For the end user, error messages should generally be clear and unambiguous as to their cause, so that they can respond meaningfully to what went wrong.
• Error messages should have a machine-readable component (e.g., an HTTP Status Code), as well as a verbose component for users to understand.
• We should also make sure they obscure the right things. Generally speaking, we probably don't want messages that expose the internal code, both because that's less professional and because it might risk exposing secret info.

Requirements

• Look into ensuring that error messages are standardized across the API. Maybe include a table of errors that could be consulted in documentation.
• Reduce the number of Internal Server Error errors that pop up during functionality.
• Ensure errors are relevant to the user and inform them about what is going wrong.

Tests

• To ensure proper functionality, we may want to expand integration tests to account for various errors.
• At this point, however, we may want to take into account separating some of our tests to differentiate

Docs

• Create docs describing different, common errors.

Open questions

• Any uncertainties? Anything we're flexible about?

[josh-chamberlain]

+1 the idea of a table with enumerated errors