如何区分控制器故意生成的 404 和 REST API 中的实际错误？答案

【问题标题】：How to distinguish a deliberate, controller-generated 404 from an actual error in a REST API?如何区分控制器故意生成的 404 和 REST API 中的实际错误？
【发布时间】：2016-05-13 21:46:12
【问题描述】：

在 JSON-REST 服务架构中（在 these patterns 之后的方法和响应代码）我们经常需要生成故意的 404 响应 - 例如，如果 GET /users/123 被路由到控制器，然后无法找到一个 ID 为 123 的用户实体，我们返回一个 404 响应，在许多情况下将包含带有错误消息/代码/等的 JSON 有效负载。

现在，当我们为特定 API 提供客户端时，我们希望客户端在不同条件下表现不同。例如，如果我们将客户端指向错误的主机，我们可能会从该主机获得 404 未找到 - 而如果我们确实访问了服务，我们可能会因为无效的用户 ID 而获得 404。

在这种情况下，就客户端而言，“未找到 404 用户 ID”不是错误 - 与任何其他“未找到 404”相反，这会导致客户端抛出异常。

我的问题是，你如何区分这些 404 错误？

仅基于响应？

通过添加标头来指示有效响应？

还是其他方式？

【问题讨论】：

GET /users/123 是任何客户端的允许操作吗？还是只有 user123 可以查看，等等？因为如果由于任何类型的安全问题，“403 Forbidden”可能更准确（和 RESTful）。
是的，如果服务请求被拒绝，我们会发出 403 代码 - 这些代码不容易被误认为是其他任何东西。但在 404 的情况下，可能有多种原因，例如访问错误的服务器、服务已关闭、服务未正确路由请求等 - 所以客户端需要一些方法来区分“成功” " 404，客户端可能会从实际错误中返回null，客户端可能会为此引发异常。

标签： json api rest http microservices

【解决方案1】：

在这两种情况下都可以返回 404。由于4xx代码是客户端相关代码，所以即使有错误也可以返回内容。

现在，可以根据响应的正文来确定它是哪种 404。请记住，响应应该带有与客户端提供的Accept 标头兼容的mime-type。因此，如果客户端“知道”您的特定错误描述格式，您的服务器可以回答更详细的描述。

通过这种方式，服务器可以决定客户端是否会理解 404 的详细响应，并且客户端也可以理解它何时收到常规 404，或者它可以处理的消息.

这在语义上是正确的，并且与 HTTP 兼容。

【讨论】：

我开始沿着这些思路思考，但是您关于检查客户端内容类型的观点非常重要 - 如果您收到的响应来自错误的主机。