API是必需的状态方法吗？

Question

我正在构建一个API，我想知道是否值得在API中使用一个方法来返回API的状态，无论它是否存活？

或者这是没有意义的，它的API用户工作只能调用他们需要的方法，如果由于网络问题它没有返回任何东西，他们会根据需要处理它？

Answer 1

我认为返回状态非常有用。一方面，你可以提供比“活着”更多的状态，并使你的API更强大，另一方面，它对用户更有用，因为你可以告诉他到底发生了什么（例如'维持' ）。

但是，如果您的WebService由于网络问题而根本不可用，那么当然，由用户来捕获该异常。但这不是重点，我想，这不是你用API控制的东西。

Answer 2

没用。

它返回给你的信息完全过时，因为服务可能会在调度状态返回调用后立即失败。

此外，如果您负载均衡传入请求并且您的状态请求被路由到失败节点，则回复（或缺少回复）会向客户端看起来像整个API服务的问题。与此同时，所有其他节点都可以愉快地为请求提供服务。现在您的客户端会认为整个API服务已关闭但后续请求可以正常工作（假设您的负载均衡器会删除失败的节点或重新启动它）。

从应用程序的请求返回的HTTP状态代码是指示可用性的正确方法。当然，您的客户必须经过编码以容忍和处理它们。

Answer 3

标准HTTP响应状态代码有什么问题？我想起了503 Service Unavailable。 HTTP客户端应该已经能够处理它，而无需为API编写任何特殊代码。

现在，如果服务可能经常不可用，并且客户端发现但服务器价格便宜是昂贵的，那么单独进行“健康检查”可能是合适的可以快速让客户知道该服务可用的URL（在运行状况检查URL上获取GET时）。

Answer 4

大部分时间都没有必要。至少当它返回简单的true或false时。它只是使客户端代码更复杂，因为它必须再调用一个方法。即使您的客户端从服务中收到active = true，下一个有用的呼叫仍可能失败。让客户端在正常执行期间进行所需的调用，并让它们正确处理网络，超时和HTTP错误。这种情况的非常有用的模式称为Circuit Breaker。

状态检查可能有用的原因：

• 如果所有正常呼叫都被认为是昂贵的，那么首先调用轻量级状态检查方法（仅为了避免昂贵的呼叫）可能是有利的。
• 服务可以具有不同的状态，客户可以根据这些状态更改其行为。

也许值得研究像XMPP这样的有状态协议。