2012-09-19 27 views
3

我正在寻求将web hooks作为应用程序REST API的一部分来实现。为批量操作实现Web挂钩

最初我们希望实现API消费者的机制来注册实体更新的事件。因此,如果实体发生变化,我们会调用所有在该实体上注册更改事件的webhook(并且作为注册过程的一部分,API消费者可以包含额外的过滤标准,以确保他们只接收对他们感兴趣的实体子集的回调在)。

现在 - 这对用户启动的更改非常有效,它将缓慢地流入,但我担心在发生大量更改时如何最好地处理此问题 - 例如,作为在群集中执行的批量操作的一部分UI或API消费者发生的大量更改。

到目前为止,我还认为:

  • 只是做了回调为每个实体,使用某种异步池 - 问题,我在这里看到的是规模和可能造成的危害这些应用程序订阅网络挂钩。
  • 排队每个webhook注册更改记录,比如说10秒的窗口,然后推送一个webhook通知到订阅与受影响的实体列表 - 我在这里看到的问题是,我们在行动之间引入不必要的延迟和webhook,当事件只是在流淌时 - 这也引入了一些开销和复杂性,特别是如果在web场场景中实现这一点。
  • 实际上将批量操作暴露为网页挂钩 - 所以如果执行批量删除,消费者会订阅此操作。因此,为单个实体更改设置挂钩将不会收到批量更新/删除等任何实体更改事件 - 它们必须通过批量操作Web挂钩来处理此事件。

由于一些额外的细节 - 在这个应用程序中的批量操作可能会包含10到10万个实体之间的任何地方。

是否有人对批量操作实施了Web钩子,这些批量操作可以阐明他们如何决定实现这一点?

+0

我也有所有这些问题,再加上在调用webhook时不阻止主HTTP处理。你最终采用了什么解决方案?你对2017年有何建议? (最好用Python/Lambda) –

回答

1

我们最近实现了Web钩子作为我们其余API的一部分,我们主要关心的还是批量操作。在我们的情况下,它是批量导入,用户可以通过我们的Web应用程序将记录导入到excel或csv文件中。

我们的导入过程是以这样一种方式设计的,即整个过程在一个事务中运行。所以如果失败了,我们只需回滚一下,什么都不做,如果成功完成,我们会向拥有一个庞大身份的订阅客户端发布一个Web钩子通知,并提供关于受影响实体的信息。

现在我不确定在您的应用程序中如何执行批量操作。如果它在一个交易中,那么你没有问题。其他方面,我建议保持单独和批量操作Web挂钩分开。我想这是使用webhooks的一个缺点,你可以通过背靠背POST请求来降低你的订阅者。