Plan error response strategy

[rnowling]

RFC7807 defines suggested fields to be included when returning an object describing errors:

• "type" (string) - A URI reference RFC3986 that identifies the problem type. This specification encourages that, when dereferenced, it provide human-readable documentation for the problem type.
• "title" (string) - A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization.
• "status" (number) - The HTTP status code generated by the origin server for this occurrence of the problem.
• "detail" (string) - A human-readable explanation specific to this occurrence of the problem.
• "instance" (string) - A URI reference that identifies the specific occurrence of the problem. It may or may not yield further information if dereferenced.

In our case, we would need to define an ontology of error types and generate appropriate descriptions and documentation. This may not be feasible to implement entirely in the short term. We can, however, generate human-readable titles, statuses, and details.

The primary outcome of this issue is to determine a standard for responding to error messages in a consistent manner and add it to the developer documentation.

[rnowling]

Spring has its own approach to error messages that might be worth copying. See this article.