在我的网站中，我想创建一个公共API，允许客户（未知的人）与我的服务进行交互。在这种情况下，经典的REST API可以很好地工作。
但是，我也需要能够向客户发送事件。这些事件与客户端HTTP请求无关。我看到＆＃34; webhooks＆＃34;是一种解决这个问题的方法。如果我理解，使用webhooks，我的服务会将HTTP POST请求发送到客户端指定的URL，并在此请求中包含事件数据。
我认为websocket也可以用作满足这种全双工通信需求的解决方案。
我想知道的是，客户实施与我的服务交谈最简单的方法是什么？简洁是这里的关键点。 困难的是我的客户可以使用各种技术（带有HTTP服务器的完整网站，没有服务器的iOS / Android应用程序等）。
如果我使用REST API + webhooks，对客户有什么影响？ WebSockets的？等等？ 如何做出选择？
希望它清楚（但不确定）。谢谢:)）
答案 0 :(得分：6)
我认为webhooks是一个更简单的解决方案。是的，您理解得很清楚，使用您的API的开发人员会注册一个URL，您的后端将POST事件数据。这是API中常用的模式。
使用webhooks设计的一大好处是客户端/服务器连接不需要保持打开状态。毕竟，如果不经常发生事件（即每小时或每天只发生几次）或保持一致的连接打开是一项挑战，只有在需要时建立连接才是相当有效的。
为您提供webhooks的挑战，API提供商，正在设计一个事件后端系统，该系统处理状态检测的变化和可靠的webhook调用机制（即处理无响应或抛出错误的webhook接收者URL）。
在开发人员端使用webhooks的挑战是他们需要站起来一个可靠的Web服务器来监听来自服务器的事件POST数据。
实时 API（即基于Websockets，Bayeux / CometD）真的很膨胀，因为实时连接意味着不必建立新的连接，这对于非常有用健谈。此外，还有很多项目和公司在服务器和客户端上使用完全出炉的库来解决繁重问题。其中之一是Fanout.io，只需几行代码就可以在客户端/服务器之间推送消息，尽可能利用XMPP，Bayeux和Websockets。
（我与Fanout无关，但我已经使用过它了）
所以，总而言之，webhooks很简单，主要是因为你已经熟悉了实现它们所需的架构，而且模式很好。如果您倾向于使用持久连接方法，我会查看像Fanout这样的工具/平台，因为它会处理繁重的工作（即订阅/发布，并发连接规模，客户端/服务器库）。