上游服务故障的REST API状态代码？

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

我觉得HTTP 500不合适，因为问题不是（正如RFC定义的那样）一个“内部服务器错误”。服务器很好，仍然能够处理其他请求而不会崩溃，只是功能降级，直到其他服务恢复联机

---

我考虑过

502-坏网关

，因为应用程序实际上是作为另一个服务（类似）的代理，或者可能

503-服务不可用

，因为这是一个事实上不可用的服务，但他们感觉不完全正确。尤其是最后一个，因为它的含义是由于负载或太多的请求需要处理而不可用

您不应该从（api提供者）的角度来看待它，而应该从消费者的角度来看待它。您应该能够向您的消费者解释他们在收到特定状态代码时应该如何行动。他们的行为应该与你发送500美元时有什么不同

作为一个api消费者，我真的不在乎哪里出了问题。我有一个单独的接口可以使用，这就是您的公共api。您选择如何实现此接口背后的api与我无关

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

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

这是w3.org所说的：

由于发生错误，服务器当前无法处理该请求 临时服务器过载或维护。这意味着 这是一种暂时的情况，经过一段时间后会得到缓解 延迟如果已知，延迟的长度可以在 在标头之后重试。如果之后没有重试，则客户端应该 像处理500响应一样处理响应

您可以（而且确实应该）做的是在正文中返回一条错误消息。如果您的api是json api，那么您应该返回json格式的错误消息

不要想着好看。考虑清楚和可预测。服务器遇到意外情况，无法满足请求

编辑：您提到数据库，在数据库超时的情况下，它肯定是500

---

/JP

它应该更像你从上游服务收到的任何东西，如果它的503:service Unavailable，那么你返回503:service Unavailable如果它的500，你也返回500

是的，DB是一个坏例子，我同意这一点。在实际案例中，我真正关心的是上游服务。我理解你的观点，客户并不关心，但作为一个客户，我确实关心它是什么类型的500，因为有些暗示暂时的问题，有些暗示特定的资源，有些暗示整个应用程序崩溃（500）。我理解你说的“好看”是什么意思，但我真正关心的是向我的客户发送正确的信息，以便他们能够正确处理。你能给出一个具体的场景吗？什么样的服务不可用，为什么不可用。在这种情况下，您希望客户具体做什么。