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