在我的网站中，我想创建一个公共(public) API，允许客户(未知人员)与我的服务进行交互。在这种情况下，经典的 REST API 可以很好地工作。
但是，我也需要能够向客户端发送事件。这些事件与客户端 HTTP 请求无关。我看到“webhooks”是处理这个问题的一种方式。如果我理解得很好，使用 webhook，我的服务会将 HTTP POST 请求发送到客户端指定的 URL，并在该请求中包含事件数据。
我认为 websocket 也可以用作这种全双工通信需求的解决方案。
我想知道的是，哪种方法最容易让客户实现以与我的服务对话？简单是这里的关键点。 困难的是我的客户可以使用各种技术(带有 HTTP 服务器的完整网站、没有服务器的 iOS/Android 应用程序等)
如果我使用 REST API + webhooks 对客户有什么影响？网络套接字？ ETC？ 如何做出选择？
希望它很清楚(但不确定)。谢谢:)
最佳答案
我认为 webhooks 是一种更简单的解决方案。是的，您理解得很好，使用 webhook，使用您的 API 的开发人员将注册一个 URL，您的后端将在其中发布事件数据。这是 API 中使用的常见模式。
使用 webhooks 设计的一大好处是客户端/服务器连接不需要保持打开状态。毕竟，如果事件不经常发生(即每小时或每天只有几次)或保持一致的连接打开是一个挑战，则仅在需要时建立连接是相当有效的。
作为 API 提供者，使用 webhook 的挑战在于设计一个事件后端系统来处理状态变化检测和可靠的 webhook 调用机制(即处理无响应或抛出错误的 webhook 接收器 URL)。
在开发人员端使用 webhook 的挑战在于他们需要建立一个可靠的网络服务器来监听来自您的服务器的事件 POST 数据。
实时 API(即基于 Websockets，Bayeux/CometD)非常流行，因为实时连接意味着不必建立新连接，这对于非常聊天的 session 特别有用.此外，还有许多项目和公司已经使用完全烘焙的库来处理服务器和客户端的繁重工作。其中之一是 Fanout.io这使得只需几行代码就可以在客户端/服务器之间推送消息，并尽可能使用 XMPP、Bayeux 和 Websockets。
(我不隶属于Fanout，但是我用过)
因此，总而言之，Webhook 之所以简单，主要是因为您已经熟悉实现它们所需的架构，并且该模式是一种广为流传的模式。如果您倾向于持久连接方法，我会看看像 Fanout 这样的工具/平台。因为它负责繁重的工作(即订阅/发布、并发连接规模、客户端/服务器库)。
关于web-services - 如何在 API 和各种客户端之间创建全双工通信？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/28841697/