rest - API:用于多个项目的 HTTP 状态代码发现错误？

Question

假设有一个查找 API 端点。响应可能成功(200)，未找到(404)，......在我的情况下 发现不止一件 是一个错误。哪个 HTTP 状态代码可以最好地描述多个项目发现错误？

Answer 1

Suppose there is a lookup API endpoint. A response can be successful (200), not found (404), ... and in my case more than one item found is an error. Which HTTP status code can describe more than one item found error the best?

服务器完全理解请求，但无法提供符合其契约(Contract)部分的表示。
所以正确的错误代码将在 5xx 中范围。

The 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method.

如果没有一个专门的 5xx 错误代码适合，你应该使用 500

The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.

Michael Kropat 在枚举 Stop Making It Hard 中的选项方面做得很好。 .他对 502 做了这个有趣的观察

I can tell you we would have saved hours upon hours of debugging time if only we had distinguished 502 Bad Gateway (an upstream problem) instead of confusing it with 500 Internal Server Error.

“网关”的现代定义可以在 RFC 7230 section 2.3 中找到。 (中介)。

A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as an origin server for the outbound connection but translates received requests and forwards them inbound to another server or servers. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance through "accelerator" caching, and to enable partitioning or load balancing of HTTP services across multiple machines.

All HTTP requirements applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification.

非常非常粗略地，500 是“我的坏”，其中 502/504 将手指指向其他地方。

what error code would you use for my case?

根据您的描述，500。这适用于“我对该资源的表示已损坏”。
合理的选择是 502，它适用于“此资源的上游表示已损坏”。
在任何一种情况下，错误的受众都是内部的(客户无法做任何事情来纠正问题。您的支持团队可能无法对状态代码之间的区别做任何有用的事情)。您可以合理地争辩说，问题出在上游的事实是客户不感兴趣的实现细节(所以 500 一切)。或者，您可能会争辩说您的 API 是一个网关，用于转换收到的请求并将它们转发到另一台服务器，因此状态代码应该是因为问题出在您的商店中，而不是在您的 api 中。
所以它归结为诸如“在跟踪我们在 api 中的错误数量时，我们是否想将此类问题与内部抛出的异常区分开来”？
似乎缺乏权威指导；选择一种方法，记录您的理由，然后发货。