我的问题是使用RESTful API进行错误处理。传统上，人们在响应正文中使用了错误代码和消息。我的问题是你能否将这些错误表述为完全成熟的资源。例如，您可能希望将错误作为HTML页面获取或获取json格式的可能错误列表。将错误作为资源似乎很自然。
然而，将“资源”作为另一个资源的错误返回似乎有点脏，但是如果你考虑它，请求体中的错误代码和错误消息只是没有资源的额外有用语义。
另外要明确这不应该是一个主观问题。我想知道这样做是否会违反RESTful设计原则或任何值得注意的HTTP通信相关RFC。
修改
一个问题是需要区分错误类型和错误实例。将错误类型作为资源但捕获每个可能的错误实例并报告返回不是很有用非常有用。
EDIT2：
问题的核心是，是否应将错误资源（与请求的资源不同）放入4XX / 5XX响应正文中。关于200 +错误或4XX / 5XX是否应该处理错误的问题在这里得到解答：REST API error return good practices
答案 0 :(得分：3)
虽然你肯定可以代表一个错误作为资源，但你的主要问题是客户会发现很难将错误理解为错误;他们会将成功返回代码解释为整体成功。那是错的！ （我们在其中一个正在运行的Web应用程序中遇到了这个问题，它通过发送一个文件来处理错误，该文档的一个字段表示存在错误。这是一个彻头彻尾的痛苦一旦我们切换到使用真正的错误代码，客户工作得更好。）
为了缓解这种情况，请返回带有错误的JSON描述（4 **和5 **消息的有效负载），描述包含更多信息的资源的位置;错误仍然是错误，但现在他们的错误与丰富的超链接信息。这是RESTful，实际上非常好！您可能也应该有一些方法让客户通过其他机制发现他们应该知道的错误资源，例如列出他们有权查看的资源的/previous-errors资源。毕竟，可发现性也是一个很好的REST原则;状态应该是资源状态（尽可能多），并且需要尽可能少地存储在客户端中。