REST API 心跳标准

Question

对于通过 REST API 提供服务的 SaaS 产品，拥有心跳 API 是否是标准要求？

我在工作中就这个主题进行了辩论，在我看来，心跳 API 是多余的——在中断的情况下，我们有一个状态页面，它正是针对这类问题，状态页面 + 正确的通信，

对于我们 API 的常规使用 -> API 应该按原样使用，并且应该有一个经过适当处理的故障转移 - 取决于使用者和响应代码(写入日志、重试等...)

另外，我从未遇到过提供心跳端点的 API 产品，在网上查找时，我遇到了 Opsginie 心跳代理功能和其他一些我不认为它们是标准 API 的心跳，

您是否遇到过这样的 API 需求，或者遇到过提供心跳端点的 API 产品？这对我来说真的很有用。

Answer 1

这是个好问题。我的建议是关注 API 的消费者和他们的期望——即 API 的任务关键程度如何？如果您的系统遇到严重问题，您的消费者是否会:

可能会生气并寻找通知/状态信息(即等待)？

panic 并开始提高优先级支持电话？

如果您的消费者认为您的 API 对任务至关重要，那么他们很可能正在寻找一种自动检测问题的方法，即使他们目前并未将 API 用于其主要目的。许多关键任务系统都连接到客户端的监控系统中，因此对于某些用户/客户端/消费者来说，心跳可能被认为非常重要。

如果通常不是关键任务，那么您的消费者可能永远不会使用它，因此无需实现。

我希望这会有所帮助。