API钩子/回调的最佳实践？

Question

假设我有web应用程序/服务：

• API接口
• 一组应用程序

API用于管理某些资源(简单的CRUD操作)。现在我需要的是订阅应用程序以适应不同API资源的更改。应用程序将对更改做一些背景工作。

我想到了回调的想法。这样，应用程序就可以使用oauth，并将回调配置发布到API。

我认为这个配置应该如下所示：

{
  'callback_url': 'http://3rdpartyservice.com/callback',
  'resources':    ['foo1', 'foo2'],
  'ref_data':     { 'token': 'abcd1234' }
}

• 资源是第三方服务感兴趣的资源的数组。
• ref_data是用于第三方使用的自定义json (例如用于auth)。

通过这种方式，对于指定的资源更改，API将向callback_url发送请求。此请求将包含资源数据、操作(创建/更新/删除)和ref_data。

这里的目的是使这个通用化，允许第三方客户端配置这样的回调.

所以问题是：

1. 有什么最佳做法吗？
2. 安全隐患呢？
3. 网络上有没有真实世界的例子？

发送

Answer 1

听起来非常类似于WebHooks或Service。

查看GitHub上的网络钩子，了解它们是什么以及它们是如何工作的。还请参见alinea 服务钩，因为它解释了github如何处理这些WebHooks。这对于您的应用程序来说也是类似的。OAuth解释了为什么和如何做到这一点。

另见Webhooks，REST和Open，来自API用户体验。

甚至还有RestHooks。

Answer 2

这种需求的一般解决方案通常称为“发布/订阅”。有数十种解决方案-谷歌“发布订阅REST”的一些例子。你也可以读"企业集成模式“。

这种解决方案的关键挑战是“实时对队列”。

例如，如果您有一个API，其中有100万个客户机，它们都对同一个事件感兴趣，那么您就不能保证在应用程序要求的任何时间框架内，您都可以实时地到达所有这些客户端。你也必须担心网络会消失，或者客户暂时关闭。在这种情况下，应用程序可能定义一个事件队列，客户端在该队列中查找他们感兴趣的事件。一旦你沿着这条路走下去，你可能会使用一些现成的软件，而不是自己的软件。阿帕奇骆驼是一个很好的开源实现。

例如，在您的示例中，如果无法到达3rdpartyservice.com，会发生什么情况？还是http://3rdpartyservice.com/callback在向foo1发布更新时抛出错误，而不是向foo2发布更新时抛出错误？或者，如果http://3rdpartyservice.com/使用了不同于您习惯的OAuth的味道？你如何保证http://3rdpartyservice.com/是你在发布更新，而不是黑客？

你的选择实际上倾向于你的非功能性需求，而不是功能性的需求--比如正常运行时间、通知保证、交付保证等等，都比你如何传递参数的细节，以及它是“基于资源的”还是其他协议更重要。