我遇到了名为webhook和publisher / subscriber的概念。在webhook中，第三方应用程序在依赖应用程序中发生更新时发送信息，第三方将向您的应用程序的提及URL发送HTTP发布请求，并且在发布者和订阅者中，订阅者将注册该主题并且发布者写入该主题然后注册商（如第三方）将根据订阅的主题将信息发送给订阅者。
两者是相似还是不同？
我很困惑任何人都可以解决这个问题吗？
答案 0 :(得分：2)
嗯，从概念上讲，这两种方法都用于在事件发生时通知客户端。 但实际上我会在两种不同的场景中使用它们。 webhook （来自维基百科）：
Web开发中的webhook是一种使用自定义回调来增强或改变网页或Web应用程序行为的方法。这些回调可能由第三方用户和开发人员维护，修改和管理，这些用户和开发人员可能不一定与原始网站或应用程序相关联。术语＆＃34; webhook＆＃34;由Jeff Lindsay于2007年从计算机编程术语钩子中创造出来。
当您希望在后端服务器的第三方之间传递异步更改或更新时，webhook方法是相关的。
这意味着第三方需要为每个客户注册webhook地址，并触发一个http请求，其中包含需要传达的信息。
使用webhook的一些注意事项是，在webhook地址没有响应或任何给定的临时故障的情况下进行故障处理，重试责任和处理由发布者完成。
以下是使用webhook方法的几个例子：
- SendGrid.com - 一种电子邮件服务，让您通过api发送电子邮件和活动电子邮件。如果您希望每次用户取消订阅列表时收到通知，您希望在后端公开Webhook的一个示例。
- Braintree.com - 一个计费网关，可让您向客户收取他们在您网站上购买的产品的费用 - 例如，您在后端公开的webhook，以便在每次成功执行定期付款时收到通知
对于发布者/订阅者，这更像是一种消息模式（来自维基百科）：
在软件体系结构中，发布 - 订阅是一种消息传递模式，其中消息的发送者（称为发布者）不会将消息编程为直接发送到称为订阅者的特定接收者，而是将发布的消息分类到类中，而不知道哪些订阅者如果有的话，可能会有。同样，订阅者表达对一个或多个类的兴趣，只接收感兴趣的消息，而不知道哪些发布者（如果有的话）。
优点
松耦合
发布者与订阅者松散耦合，甚至不需要知道它们的存在。以主题为重点，允许发布者和订阅者不知道系统拓扑。无论如何，每个都可以继续正常运行。在传统的紧密耦合的客户端 - 服务器范例中，客户端无法在服务器进程未运行时将消息发布到服务器，除非客户端正在运行，否则服务器也不能接收消息。许多发布/订阅系统不仅将发布者和订阅者的位置分离，而且还在时间上将它们分离。中间件分析师使用此类发布/订阅系统的常用策略是取消发布者以允许订阅者处理积压（带宽限制的形式）。 的可扩展性
通过并行操作，消息缓存，基于树或基于网络的路由等，提供比传统客户端 - 服务器更好的可扩展性的机会。但是，在某些类型的紧密耦合的大容量企业环境中，随着系统扩展到成为数千个服务器共享发布/订阅基础设施的数据中心，当前的供应商系统往往失去这一优势;在这些环境中高负荷下的pub / sub产品的可扩展性是一项研究挑战。 另一方面，在企业环境之外，pub / sub范例已经证明其可扩展性远远超过单个数据中心的容量，通过RSS和Atom等Web联合协议提供Internet范围的分布式消息传递。这些联合协议接受更高的延迟和缺乏交付保证，以换取甚至低端Web服务器将消息联合到（可能）数百万个单独的订户节点的能力。 的缺点
发布/订阅系统最严重的问题是其主要优势的副作用：发布者与订阅者的脱钩。
关于pub / sub的更多信息，我推荐以下帖子：
答案 1 :(得分：1)
Webhook是一种基于HTTP的PubSub技术实现，它使Webhook技术成为PubSub的一个子集。除了Webhooks，PubSub还可以使用其他订阅和发布方式（例如电子邮件）。