微软发布了 ASP.NET WebHooks 预览版

阅读数:1489 2015 年 11 月 15 日

话题:.NET语言 & 开发架构

微软近期发布了 ASP.NET WebHooks 的预览版,这是一个可用于创建及使用 Webhook 功能的库。WebHooks 支持 MVC 5 及 WebApi 2。

Webhook 是一种通过 HTTP 实现用户自定义回调函数的模式。客户可以选择订阅某些类型的事件,并在这些事件实际发生时以 POST 请求的方式接收这些事件。Webhook 的一大要点在于它是使用 HTTP 实现的,这也意味着利用或实现这项技术无需任何新的基础设施的支持。

ASP.NET WebHooks 为 Webhook 的发送与接收操作提供了基础构建块。在接收端,它提供了一种通用的模型,用于接收并处理来自于 Webhook 提供者的事件。而在发送端,它则提供了对管理订阅与发送事件功能的支持。

InfoQ 与来自微软 ASP.NET 团队的 Henrik F Nielsen 和 Brady Gaster 进行了一次访谈,以了解该项目更多的细节信息。

InfoQ:成立 ASP.NET WebHooks 这一项目的动机是什么?

ASP.NET WebHooks 成立的动机有两方面

  1. WebHooks 为 HTTP 服务的整合提供了一种协议模式,从而能够通过 HTTP 请求的形式建立一种非常简单的事件通知模型。通过对某个 Webhook 的订阅,你就能够关注其他服务上的更新,并在更新时获得通知。这样一来,就有大量的整合场景成为可能。你将能够与其他的服务进行交互、在变更时获得通知、并进行相应的操作。这种整合可以包括任何形式,例如在 Dropbox 中上传了某个新文件、在 Trello 中新建了一个 Issue、或是通过 PayPal 进行了一次支付操作。随着 WebHooks 的应用不断增多,这种应用场景也将产生指数级的增长。
  2. 虽说这一模式本身并不复杂,但还是有一些基本的规则需要处理。包括安全模型、数据格式、以及基于这一基本模式的各种变体。麻烦的地方在于,目前大多数的 Webhook 提供者在处理这些基本规则时都存在着细微的差别。这种差别就像雪花一样,虽然每片雪花看起来都很相似,但多多少少存在着一些特别之处。ASP.NET WebHooks 的目的就是处理所有这些繁琐的部分,提供一个统一的用户模型,并让用户能够快速开始进行在服务间进行整合的任务

InfoQ:Webhook 除了 HTTP 之外并没有其他任何确立的协议,那么在发送方是否会存在某些方面的限制因素?(作为接收者来说)ASP.NET WebHooks 是否能够自动兼容那些目前已经提供 Webhook 的服务呢?

HN:我们已经在项目中提供了针对各种服务的 Webhook,例如 Azure

Alerts、BitBucket、Dropbox、GitHub、Kudu、Instagram、

MailChimp、PayPal、Pusher、Salesforce、Slack、Stripe、Trello,以及 WordPress,不过要添加对其他提供者的支持也是很简单的,并且所支持服务的名单还在不断地增长中。事实上,对于 Kudu 和 BitBucket 的支持是来自于社区所提交的 pull 请求,我们也正在添加对更多的提供者的支持。

InfoQ:到 WebHooks 正式发布为止,它的路线图是怎样的?

HN:关于正式发布的计划,我们现在还没有什么正式的说法,不过我们很乐于倾听来自社区的反馈,并接受他们的贡献,包括 pull 请求和各种建议

BG:我们从社区中获得了一些反馈,他们希望能够对 WebHook 接收消息的功能进行调试,就像在本地进行调式一样。他们也欣赏远程调试的想法,但更愿意能够通过点击“F5”来启动他们的项目并发送 Webhook。我们目前正在为某些想法设计原型,争取为 Visual

Studio 带来这一特性。

ASP.NET WebHooks 是一个开源项目,托管在GitHub平台上。

查看英文原文Microsoft Releases ASP.NET WebHooks Preview