REST API 中错误结构的最佳实践是什么？我知道我应该使用 HTTP 中的代码来描述它（REST API error return good practices），但是结构总是有用的，我发现自己总是使用诸如错误类型和错误原因之类的东西（raise CanNotCreate('Because of this')） .
定义错误消息结构的最佳做法是什么？您能否举一个具有良好错误处理能力的特定 API 的示例？
【问题讨论】：
我通常在响应状态的原因短语中指明“类型”（例如：409 Cannot Create，而不是更典型的409 Conflict），因为它是机器可解析的，无需解析 HTML 等媒体类型， XML 或 JSON。一般来说，Reason-Phrase 足以让机器客户端做任何适当的事情，特别是当给定的资源可能由于稍微不同的原因返回相同的代码时。
然后，在响应正文中，以您在其他地方使用的相同媒体类型为程序员和最终用户提供更多信息；例如，如果请求成功并返回带有 JSON 的 200 OK，则返回带有错误响应的 JSON。否则真的会让针对您的 API 进行开发的人们感到沮丧。
最后，如果您的媒体类型允许，请尽可能在响应中包含超链接，以帮助客户找到问题的解决方案。
【讨论】：