REST API 心跳标准

Question

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

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

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

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

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

Answer 1

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

1. 可能很生气并寻找通知/状态信息（即等待）？
2. 恐慌并开始提高优先级支持电话？

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

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

希望对你有帮助。