REST API 心跳标准

REST API heart beat standard

对于通过 REST API 提供服务的 SaaS 产品，是否有检测信号 API 的标准要求？

我在工作中有一个关于这个主题的争论，在我看来，心跳 API 是多余的 - 如果发生中断，我们有一个状态页面，它正是针对这些问题，状态页面+适当的沟通，

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

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

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

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

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

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

希望对您有所帮助。