3

我希望将Web 挂钩作为应用程序 REST API 的一部分来实现。

最初，我们希望为 API 消费者实现一种机制来注册实体更新事件。因此，如果一个实体发生更改，我们会调用所有已为该实体上的更改事件注册的 webhook（作为注册过程的一部分，API 使用者可以包含额外的过滤条件，以确保他们只接收他们感兴趣的实体子集的回调在）。

现在 - 这对于用户发起的更改效果很好，会慢慢渗入，但我担心当大量更改发生时如何最好地处理这个问题 - 例如作为在 UI 中执行的批量操作的一部分，或者API使用者发生的大量变化。

到目前为止，我已经考虑过：

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

作为一些额外的细节 - 此应用程序中的批量操作可能包含 10 到大约 100,000 个实体。

有没有人为批量操作实施了网络挂钩，可以阐明他们如何决定实施这一点？

4

1 回答 1

1

我们最近实现了 web 钩子作为我们的 REST API 的一部分，我们主要关心的也是批量操作。在我们的例子中，它是批量导入，用户可以通过我们的网络应用程序导入 excel 或 csv 文件中的记录。

我们的导入流程被设计成整个流程在一个事务中运行。因此，如果它失败了，我们只是回滚并且什么都不做，如果它成功完成，我们会向订阅的客户端发布一个 web hook 通知，其中包含一个巨大的主体，其中包含有关受影响实体的信息。

现在我不确定在您的应用程序中如何进行批量操作。如果它在交易中，那么你没有问题。否则，我建议将单动作和批量动作网络挂钩分开。我想这是使用 webhook 的缺点之一，你可以通过背靠背的 POST 请求来降低订阅者的数量。

于 2012-09-20T18:53:04.180 回答