我是否可以使用HTTP状态代码的自定义原因来区分REST API的错误

Question

我想区分不同类型的“未找到”错误。例如，给出以下请求：

GET /author/Adams/works/HHGTTG

作者可能“找不到”或者作品可能“找不到”，我想区分两者。

状态：404 - 作者未找到
状态：404 - 找不到工作

根据规范，可以改变原因短语。 http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html

  

6.1.1状态代码和原因短语

     

......此处列出的原因只是建议 - 它们可能会被当地的等价物替换，而不会影响协议......

对同一状态代码使用两个独特的短语也可以接受吗？

而且，这是一种合理的方法，还是有更好的约定来表示更细微的错误？

最终我希望有一个客户端库可以抛出AuthorNotFound或WorkNotFound异常，而不是一般的AuthorOrWorkNotFound异常。

Answer 1

您可以让HTTP响应的正文包含一条消息，您可以使用任何其他信息进行解析。

状态代码（在响应中）上的HTTP状态消息可以是您想要的任何内容，它不会影响任何客户端。 HTTP客户端通常会忽略消息文本。

Answer 2

使用“阴影”未找到的方法时，您可以使用404与响应正文：

• 使用404状态和文本详细信息（'找不到作者'，'找不到工作'）。为了更灵活的语言，您可以使用标签（如error.author.notFound）
• 使用更结构化且更容易解析“子节点”（例如，10个代表作者未找到，11个用户未找到）。

我仍然不推荐上面提到的子代码，它们为统一的HTTP接口增加了很多复杂性和维护工作。以不同方式构建api-client库。让它先调用/author/adams/work/11。如果它返回404，则在旁边调用/author/adams/以查明是否是导致404的缺失作者。然后，您可以抛出相应的NotFound异常。

另一种选择是以不同方式设计结束api-client应用程序。它首先应该调用/author/adams然后如果不是404将继续/author/adams/work。因此，应用程序本身就是在走下去的路径。但是，这当然只有在前端内部的页面流适应此调用序列时才有效。