我在/status有一个运行状况检查端点，该端点返回以下状态代码和响应正文：
200 OK ? 503 Service Unnavailable 降级响应的HTTP状态代码应该是什么？ “降级”支票用于did succeed but are slow or unstable的支票。哪种HTTP状态代码最有意义？
答案 0 :(得分：2)
考虑返回在 2xx Success 范围内的自定义代码，该代码在已知/公共状态代码中尚未使用。类似于某些不受任何标准支持的unofficial codes。
例如218 This is fine (Apache Web Server)
用作全面错误条件，用于在启用ProxyErrorOverride时允许响应主体流经Apache。在Apache中启用ProxyErrorOverride时，Apache会自动丢弃包含4xx或5xx状态码的响应正文，而转而使用ErrorDocument指令指定的通用响应或自定义响应
做完一些研究后，我遇到了一个草稿
Health Check Response Format for HTTP APIs: draft-inadarei-api-health-check-03
他们在哪里也提出了类似的建议
在“警告”状态的情况下，端点必须返回2xx-3xx范围内的HTTP状态，并应利用响应的可选字段提供附加信息。
草案中warn的状态为healthy, with some concerns，我认为这与您想要的模型非常一致。
虽然不确定，但我认为它提供了一些想法来帮助最终设计。
答案 1 :(得分：2)
在上游服务器端进行健康检查时，我会警惕像这样将头发分开。提供运行状况检查的服务应根据自己的一组策略或规则（请求超时，连接失败等）轻而易举地（并发地）测试其所有上游依赖性。实际上，运行状况检查会起作用还是无效，并且应用程序实际上不需要跟踪运行状况检查的结果（除了捕获有关所发生情况的度量标准之外）。恕我直言，有状态的健康检查是灾难的秘诀。
我通常使用以下界面进行应用程序运行状况检查：
204 - No Content, everything is working within tolerences
500 - Something failed, and here's some details in the response about what went wrong
棘手的地方取决于您的体系结构。您可能有一个VIP或反向代理来解释此响应并确定给定节点是否健康，在这种情况下，它将把请求路由到健康节点或返回503 Service Unavailable。该决定将基于某些策略做出-在z个上游服务的y个时间段内x个运行状况检查请求失败。
如果使用网格，则每个人都可以将数据反馈到服务注册表以使运行状况保持最新，并且它可以基于实际的服务调用而不是运行状况检查。
由于客户可以跟踪服务的各种响应，因此他们可以根据其所依赖的服务的健康状况来做出决策。断路器是一种很好的解决方案，可以根据实际要求连续执行，而不仅仅是运行状况检查。断路器库（例如resilience4j）将为您执行此操作，但要建立一些策略来确定多少失败/慢速请求构成不良服务。诸如netflix eureka之类的服务注册表可以帮助发现和持续监控。
答案 2 :(得分：2)
最适合来自运行状况端点的“降级”状态响应的HTTP状态码就是200 OK。
之所以这样说，是因为在Hypertext Transfer Protocol (HTTP) Status Code Registry所指出的IANA维护的官方[RFC7231] HTTP/1.1: Semantics and Content中找不到更好的代码。应避免使用非官方代码，因为它们只会使您的API更加难以理解。
您应该设计API，以使其易于使用。资源名称，HTTP动词，状态代码等应该或多或少是不言自明的，这样，已经知道“ REST语言”的人们就可以立即了解如何使用您的API，而不必弄清模糊的名称或不寻常的状态代码。这使我进入了答案的下一部分...
关于设计的其他评论
解释5xx对任何请求的响应的最自然的方法是所讨论的操作失败。
因此，对503 Service Unavailable请求的GET /status响应表示状态检查操作本身失败。如Nkosi的答案中提到的API Health Check draft所指出的那样，只有当我们可以确定/status是健康内因时，这样的响应才有用：
健康终结点仅在组件的上下文中才有意义 它表明健康。它没有其他含义或目的。如 因此，其健康状况是组件健康状况的渠道。 客户端应假定由 健康指标适用于整个组件（例如， API或微服务）。
但是使用/status的URL路径，这并不能完全清楚地表明是健康终结点。通过查看URL，我们仅知道它返回有关某物状态的信息，但我们实际上不能确定该“物”是什么。
由于您还告诉我们，是的，实际上它是健康状况的终结点，因此我建议您将名称更改为health。我还建议将其放置在某些基本路径下，例如/things/health，以使其更清楚地表明其健康状态。
另一方面，如果/status实际上是其自身的资源，即代表某些 other 组件/事物（如其名称当前所暗示）的状态的事物，那么200 OK是成功调用的唯一合理状态，即使它指示状态为“不健康”的事物也是如此。在这种情况下，5xx意味着无法获得任何状态，并且响应有效负载中的详细信息将被认为与/status服务本身的故障有关。
因此请谨慎对待事物的名称和使用的状态码！
答案 3 :(得分：0)
假设您引用的是服务的活动性/健康检查端点的状态代码-区别于 200 OK 和 203 似乎很适用，并且符合：
Warning: 199标题，但可以包含详细信息max-age与livenessProbe.periodSeconds对齐HTTP/1.1 203 Non-Authoritative Information
Warning: 199 - "FooBar Warning Details"
Content-Type: application/health+json
Cache-Control: max-age=10
Connection: close
{"status": "warn"}