我有一个接受“令牌”的服务（外观），然后将其解码以检索一些信息（一个 id），然后调用另一个外部服务来获取一些附加信息。
{"id":"foo","other-stuff":"bar"}
由于此服务依赖于外部服务，因此有时可能会失败；但是我们希望它仍然返回它确实设法检索到的信息。
{"id":"foo","warning":"bar service is down, oh no!"}
显然在第一种情况下 200 返回码是合适的，但是当它“部分”失败时它仍然合适吗？
作为消费者，我想我更愿意只阅读状态码，然后向用户显示警告或其他任何东西；所以 200 在这里对我不是很有帮助。
有任何想法吗？
取决于外部因素的瞬时服务器端故障的正确响应代码是503 Service Unavailable. 从规范：
由于服务器临时过载或维护，服务器当前无法处理请求。这意味着这是一种暂时的情况，经过一段时间的延迟会得到缓解。如果已知，延迟的长度可以在 Retry-After 标头中指示。如果没有给出 Retry-After，客户端应该像处理 500 响应一样处理响应。
将其视为部分失败违反了整个 HTTP 的事务性质——请求要么失败，要么失败。如果由于服务器端问题而无法成功完成整个请求，则根据规范，5xx 答案是唯一合适的响应。
我不确定您的网络服务是如何工作的，但如果您确实在联系多个上游数据提供者，并且获得部分响应对客户端本身无害，您应该在自己的协议中提供它它列出了正确检索的元素，以及缓存或无法提供的元素。在这种情况下，您的响应实际上是对请求的有效回答，它应该通过200 OK. 这种情况类似于在网站上有 Twitter 提要 - 如果 Twitter 关闭，您仍然可以给出有意义的答案，其中包含“Twitter 提要当前不可用消息”以及所有其他内容。当然，仍然会发送一个有意义的答案200 OK。
在这两种情况下发送相同的状态代码不是一个好习惯。您需要验证外部服务是否已启动并正在运行。换句话说，您可以将其视为例外情况。如果外部服务未启动并运行，您可以通过异常触发该场景。在那里，您将能够赶上从该外部服务返回的状态代码。如果它适合您的解决方案，您可以发送该状态代码，或者您可以设置自定义状态代码并将其发送回客户。