您能否将错误视为RESTful API中的资源？
我的问题是使用RESTful API进行错误处理。 传统上，人们在响应主体中使用了错误代码和消息。 我的问题是你能否将这些错误制定成完整的资源。 例如，您可能想要将错误作为HTML页面获取，或者以json格式获取可能的错误列表。 将错误视为资源似乎很自然。
然而，将“资源”作为另一个资源的错误返回似乎有点肮脏，但如果您考虑它，请求正文中的错误代码和错误消息就是没有资源的额外有用语义。
另外要清楚的是，这不应该是一个主观问题。 我想知道如果这样做会违反RESTful设计原则或任何有关HTTP通信的相关RFC。
编辑：
一个问题是需要区分错误类型和错误实例。 将错误类型作为资源非常有用，但捕获每个可能的错误实例并报告返回并不有用。
EDIT2：
问题的核心是如果错误资源（不同于请求的资源）应该放在4XX / 5XX响应主体中。 有关如果200 +错误或4XX / 5XX应该处理错误的问题在这里回答：REST API错误返回最佳实践
尽管您肯定可以将错误视为资源，但您的主要问题是客户会发现很难将错误理解为错误; 他们会将成功的返回码解释为整体成功。 这是错误的！ （我们在其中一个Web应用程序工作时遇到了问题，它通过发回一个带有其中一个字段表示存在错误的文档来处理错误，这是一个完全痛苦的脖子一旦我们转向使用真正的错误代码，客户就会更好。）
为了减轻这种影响，请返回JSON描述和你的错误（4 **和5 **消息的有效载荷），描述包含更多信息的资源的位置; 错误仍然是错误，但现在它们是错误的，具有丰富的超链接信息。 这是RESTful，其实很不错！ 您可能也应该有一些方法让客户端通过其他机制发现他们应该了解的这些错误资源，例如，列出他们有权查看/previous-errors资源。 毕竟，可发现性也是一个很好的REST原则; 国家应该是资源的状态（尽可能），尽可能少地存储在客户端。