web-services - 您可以将错误视为RESTful API中的资源吗？

Question

我的问题是有关使用RESTful API进行错误处理的问题。传统上，人们在响应正文中使用错误代码和消息。我的问题是，您可以将这些错误表达为完整的资源吗？例如，您可能希望以HTML页面的形式获取错误或以json格式获取可能的错误列表。将错误作为资源似乎很自然。

但是，将“资源”作为另一个资源的错误返回似乎有点肮脏，但是如果您考虑它，则请求正文中的错误代码和错误消息就是没有资源的额外有用语义。

同样要明确的是，这不应该是一个主观的问题。我想知道这样做是否会违反RESTful设计原则或HTTP通信中任何值得注意的相关RFC。

编辑:

一个问题是需要区分错误类型和错误实例。将错误类型作为资源非常有用，但是捕获每个可能的错误实例并进行报告并不那么有用。

编辑2:

问题的核心是是否应在4XX/5XX响应正文中放入错误资源(与请求的资源不同)。关于200 + error或4XX/5XX是否应该处理错误的问题，请在此处回答:REST API error return good practices

Answer 1

虽然您当然可以将错误表示为资源，但是您的主要问题是客户将很难理解该错误为错误。他们会将成功返回码解释为整体成功。错了! (我们在工作的一个Web应用程序中遇到了这个问题，该错误通过将包含文档的一个字段发回200的文档发送回200来处理错误。一旦我们改用实际的错误代码，客户的工作就会好很多。)

为了减轻这种情况，请返回带有错误的JSON描述(4 **和5 **消息的有效负载)，这些错误描述包含更多信息的资源的位置；错误仍然是错误，但是现在它们是具有丰富的超链接信息的错误。那是RESTful，实际上还不错!您可能还应该为客户端提供某种方式，以发现客户端应通过其他机制了解的这些错误资源，例如，/previous-errors资源，其中列出了有权查看的错误资源。毕竟，可发现性也是一个很好的REST原则。状态应该是资源的状态(尽可能多)，并且应该尽可能少地存储在客户端中。