我是否可以使用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

当使用你的“shadowed” not found 方法时，你可以使用 404 和响应体：

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

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

另一种选择是以不同的方式设计最终的 api-client 应用程序。它首先应该调用/author/adams然后如果不是 404 将继续/author/adams/work。所以很自然地，应用程序本身正在下降。但这当然只有在前端内部的页面流适应此调用序列时才有效。