假设我有网络应用/服务:
API 用于管理某些资源(简单的CRUD操作)。现在我需要订阅 Applications 以更改不同的 API 资源。 应用程序会对更改进行一些后台工作。
我想到了回调。这样应用程序可以 oauth orise并发布到 API 一个回调配置。
我认为此配置应如下所示:
{
'callback_url': 'http://3rdpartyservice.com/callback',
'resources': ['foo1', 'foo2'],
'ref_data': { 'token': 'abcd1234' }
}
这种方式在指定的资源更改时, API 会向 callback_url 发送请求。此请求将包含资源数据,操作(创建/更新/删除)和 ref_data 。
此处的目的是使此通用足以允许第三方客户端配置此类回调。
所以问题是:
的Tx
答案 0 :(得分:7)
听起来与WebHooks或 Service Hooks 非常相似。
查看Web Hooks on GitHub,了解它们是什么以及它们的工作原理。另见最后一个alinea Service Hooks,因为它解释了github如何处理这些WebHooks。这与您的应用程序类似。 OAuth解释了为什么以及如何完成。
另请参阅Webhooks, REST and the Open Web中的API User Experience。
甚至有RestHooks。
答案 1 :(得分:2)
此要求的一般解决方案通常称为"发布/订阅"。有很多解决方案 - 谷歌"发布订阅REST"举个例子。您还可以阅读" Enterprise Integration Patterns"。
他们在这种解决方案中的关键挑战是"实时与队列"。
例如,如果您拥有一个拥有一百万个客户的API,他们都对同一个事件感兴趣,那么您无法保证实时可以在他们的应用程序所需的任何时间范围内覆盖所有这些客户端。您还必须担心网络消失或客户端暂时关闭。在这种情况下,您的应用程序可能会定义一个事件队列,并且客户端会在该队列中查找他们感兴趣的事件。一旦您沿着这条路线走下去,您可能会使用一些现成的软件而不是建立自己的软件。 Apache Camel是一个很好的开源实现。
例如,在您的示例中,如果您无法访问3rdpartyservice.com会发生什么?或者,如果http://3rdpartyservice.com/callback在向foo1发布更新时抛出错误,而不是向foo2发布更新?或者http://3rdpartyservice.com/是否使用了与您不习惯的OAuth不同的风格?您如何保证http://3rdpartyservice.com/发布更新的是您,而不是黑客?
您的选择实际上往往归结为您的非功能性需求,而不是功能性需求 - 正常运行时间,通知保证,交付保证等等比您传递参数的具体要求更重要,以及它是否是基于资源的"或其他一些协议。