设计RESTful API，其中包含一些依赖于上游服务的元素（例如数据库，其他Web服务等）。如果应用程序本身处于有效状态，并且仍然可以使用，但无法访问其中一个上游服务（由于网络问题或其他原因），是否有比使用更合适的状态代码HTTP 500？
HTTP 500对我来说不合适，因为问题不是（如RFC所定义的）内部服务器错误＆＃34;。服务器很好，并且仍然可以处理其他请求而不会崩溃，它只是降级功能，直到其他服务重新联机。
我考虑过502 - Bad Gateway，因为应用程序实际上充当了其他服务（有点）的代理，或者503 - Service Unavailable，因为它实际上是不可用的服务，但是它们没有感觉完全正确。特别是最后一个，因为它具有由于加载或处理请求太多而无法使用的含义。
答案 0 :(得分：12)
您不应该从您的（api提供商）角度来看待它，而是从消费者的角度来看。您应该能够向您的消费者解释他们在收到特定状态代码时应该如何行动。他们应该如何表现与发送500的时间不同？
作为api消费者，我真的不在乎哪里出了问题。我有一个单一的界面可以使用，这是你的公共API。你如何选择在这个界面后面实现api与我无关。
所以我知道，你有一个内部服务器错误。即使它完全合法，你也无法处理我的请求。因此，即使这是由下游系统引起的，您也应返回状态码500。
如果这是一个临时条件，但是你希望很快恢复，那么它是503.我仍然不在乎这是由下游服务引起的。我只关心你告诉我你希望很快恢复，所以我应该在一段时间后重试。
这就是w3.org所说的：
由于a，服务器当前无法处理请求 临时重载或维护服务器。这意味着 这是一个临时条件，在某些情况下会有所缓解 延迟。如果已知，延迟 MAY 的长度将以a表示 Retry-After标头。如果没有给出Retry-After，则客户端应该 像处理500响应那样处理响应。
您可以（并且始终应该）做的是在正文中返回错误消息。如果您的api是json api，那么您应该返回一个json格式的错误消息。
不要考虑好看。考虑明确和可预测。服务器遇到意外情况，导致无法完成请求。
编辑：你提到数据库，在数据库超时的情况下，它肯定是500。
/ JP
答案 1 :(得分：0)
它应该更像是从上游服务收到的任何内容，如果它的503：服务不可用，那么你返回503：服务不可用，如果它是500，你也返回500