设计，其具有依赖于上游服务（例如数据库，另一个web服务等）的一些元素一个RESTful API。在应用程序本身处于有效状态，并且仍可以使用，但这些上游服务的一个无法达成的情况下（由于网络问题，或者别的什么），有没有更合适的状态代码，而不是使用HTTP 500？
因为这个问题是不是（如RFC定义）“内部服务器错误” HTTP 500觉得不合适我。服务器是罚款，而且还能够处理其他请求，而不融化了，它刚降级的功能，直到其他服务重新联机。
我想过502 - Bad Gateway，因为应用程序有效地作为该其他服务（有点）的代理，或者503 - Service Unavailable因为它是这实际上是不可用的服务，但他们并没有感到完全正确。特别是最后一个，因为它拥有的是由于负载或过多的请求过程中不可用的内涵。
你不应该看它从你的（API提供商）的角度，而是从消费者的角度。你应该能够解释给你的消费者接受特定的状态代码时应该怎么做。他们应该如何从不同的表现，当你发送一个500？
作为API的消费者，我真的不在乎事情发生了错误。我有一个单一的接口工作，这是你的公共API。你如何选择实现这个接口背后的API是无关紧要的给我。
所以，就我所知，你有一个内部服务器错误。你是无法处理我的请求，即使它是完全合法的。所以，你应该返回一个状态码500，即使这是由下游的系统造成的。
如果它是一个临时的条件然而，你期望从随后很快恢复它是一个503我还不在乎，这是由下游服务引起的。我只在乎你告诉我，你希望很快恢复过来，所以过了一段时间我会再次尝试。
这是w3.org说：
服务器目前无法处理请求由于服务器暂时超载或维护。言下之意是，这是将一些延迟后可缓解暂时的状态。如果已知，该延迟的长度可以在一个Retry-After头指示。如果没有给出重发后，客户端应该处理的响应，因为它会为一个500响应。
你可以（而且确实应该这样做）做的，就是在身体返回错误信息。如果您的API是JSON API，那么你应该返回JSON格式的错误消息。
不要去想看起来很不错。想想是明确的和可预测的。服务器遇到意外情况，这防止了它从完成请求。
编辑：你提到的数据库，并在数据库超时的情况下，它是最肯定500。
/J.P
服务不可用，那么你回到503：如果503它应该更像无论ü从上游服务接收，服务不可用如果500，你还回500