API是必需的状态方法吗？

Question

我正在构建一个API，我想知道是否值得在API中返回API的状态，而不管它是否存在？

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

Answer 1

我认为这是非常有用的状态返回。一方面，你可以提供比'alive'更多的状态，并且使你的API更加强大，另一方面，它对用户更有用，因为你可以准确地告诉他发生了什么事情（例如'维护' ）。

但是，如果你的WebService是根本不可用，由于网络问题，然后，当然，这取决于用户捕获了异常。但我认为这不是重点，也不是你可以用API控制的东西。

Answer 2

标准HTTP响应状态码有什么问题？想起了503 Service Unavailable。 HTTP客户端应该已经能够处理它，而无需编写任何专门用于API的代码。现在

，如果服务可能不可用频繁，它是昂贵的客户端发现，但价格便宜的服务器，那么它可能是适当的有一个单独的“健康检查”的网址，可以快速让客户知道该服务是可用的（在健康检查URL的GET时）。

Answer 3

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

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

• 如果一切正常的呼叫被认为是昂贵的有可能是先调用轻质状态检查方法的优点（只是为了避免昂贵的调用）。
• 服务可以具有不同的状态，客户端可以根据这些状态更改其行为。

它可能也值得看看有状态的协议，如XMPP。

Answer 4

这没用。

返回完全是出于它返回到你，因为状态返回调用被分派后的服务可能无法正确时刻的日期信息。

另外，如果你是负载均衡传入的请求，你的状态请求被路由到失败的节点，得到的答复（或缺乏）将着眼于客户喜欢与整个API服务的问题。与此同时，所有其他节点都可以愉快地为请求提供服务。现在，您的客户端会认为整个API服务已关闭，但后续请求可以正常工作（假设您的负载平衡器将移除失败的节点或重新启动它）。

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