在REST API中定义错误结构

Question

REST API中错误结构的最佳做法是什么？我知道我应该使用HTTP中的代码来描述它（REST API error return good practices），但结构总是有用的，我发现自己总是使用类似错误的类型和错误的原因（raise {{ 1}}）。

定义错误消息结构的最佳做法是什么？您能举例说明具有良好错误处理的任何特定API吗？

Answer 1

我通常在响应状态的Reason-Phrase中指出'type'（例如：409 Cannot Create而不是更典型的409 Conflict），因为它是机器可解析的而无需解析媒体HTML，XML或JSON等类型。通常，Reason-Phrase足以让机器客户端做任何适当的事情，特别是当给定资源可能由于略微不同的原因返回相同的代码时。

然后，在响应正文中，为您在其他地方使用的相同媒体类型中的程序员和最终用户提供更多信息;如果请求已成功并返回{J}的200 OK，则返回带有错误响应的JSON。否则，实际上会让那些针对你的API的人感到沮丧。

最后，如果您的媒体类型允许，请在响应中包含超链接，以帮助客户端导航问题的解决方案。