上游服务失败的 REST API 状态代码？

Question

设计一个 RESTful API，其中有一些元素依赖于上游服务(例如数据库、另一个网络服务等)。如果应用程序本身处于有效状态并且仍然可以使用，但无法访问其中一个上游服务(由于网络问题或其他原因)，是否有比使用更合适的状态代码HTTP 500？

HTTP 500 对我来说感觉不合适，因为问题不是(如 RFC 定义的那样)“内部服务器错误”。服务器很好，并且仍然能够在不崩溃的情况下处理其他请求，它只是功能降级，直到其他服务恢复在线。

我想到了 502 - Bad Gateway 因为应用程序有效地充当了其他服务的代理(有点)，或者 503 - Service Unavailable 因为它是实际上不可用的服务，但他们感觉不完全正确。特别是最后一个，因为它具有由于负载或太多请求无法处理而无法使用的含义。

Answer 1

您不应该从您(API 提供者)的角度来看待它，而应该从消费者的角度来看待它。您应该能够向您的消费者解释他们在收到特定状态代码时应该如何操作。它们的行为与您发送 500 时的行为有何不同？

作为一个 api 消费者，我真的不在乎哪里出了问题。我只有一个界面可以使用，那就是你的公共(public) api。您如何选择实现此接口(interface)背后的 api 与我无关。

据我所知，您遇到了内部服务器错误。你无法处理我的请求，即使它是完全合法的。因此，即使这是由下游系统引起的，您也应该返回状态代码 500。

如果这是一个临时情况，但您希望很快恢复，那么它就是 503。我仍然不关心这是由下游服务引起的。我只在乎你告诉我你希望很快恢复，所以我应该过一段时间再试。

这是 w3.org 的声明:

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.

您可以(而且总是应该)做的是在正文中返回一条错误消息。如果你的api是json api，那么你应该返回一个json格式的错误信息。

不要想着好看。考虑明确和可预测的。服务器遇到意外情况，导致无法完成请求。

编辑:您提到了数据库，在数据库超时的情况下，它绝对是 500。

/日本