我正在寻求将web hooks作为应用程序REST API的一部分来实现。为批量操作实现Web挂钩
最初我们希望实现API消费者的机制来注册实体更新的事件。因此,如果实体发生变化,我们会调用所有在该实体上注册更改事件的webhook(并且作为注册过程的一部分,API消费者可以包含额外的过滤标准,以确保他们只接收对他们感兴趣的实体子集的回调在)。
现在 - 这对用户启动的更改非常有效,它将缓慢地流入,但我担心在发生大量更改时如何最好地处理此问题 - 例如,作为在群集中执行的批量操作的一部分UI或API消费者发生的大量更改。
到目前为止,我还认为:
- 只是做了回调为每个实体,使用某种异步池 - 问题,我在这里看到的是规模和可能造成的危害这些应用程序订阅网络挂钩。
- 排队每个webhook注册更改记录,比如说10秒的窗口,然后推送一个webhook通知到订阅与受影响的实体列表 - 我在这里看到的问题是,我们在行动之间引入不必要的延迟和webhook,当事件只是在流淌时 - 这也引入了一些开销和复杂性,特别是如果在web场场景中实现这一点。
- 实际上将批量操作暴露为网页挂钩 - 所以如果执行批量删除,消费者会订阅此操作。因此,为单个实体更改设置挂钩将不会收到批量更新/删除等任何实体更改事件 - 它们必须通过批量操作Web挂钩来处理此事件。
由于一些额外的细节 - 在这个应用程序中的批量操作可能会包含10到10万个实体之间的任何地方。
是否有人对批量操作实施了Web钩子,这些批量操作可以阐明他们如何决定实现这一点?
我也有所有这些问题,再加上在调用webhook时不阻止主HTTP处理。你最终采用了什么解决方案?你对2017年有何建议? (最好用Python/Lambda) –