微软近期发布了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 成立的动机有两方面
- WebHooks 为 HTTP 服务的整合提供了一种协议模式，从而能够通过 HTTP 请求的形式建立一种非常简单的事件通知模型。通过对某个 Webhook 的订阅，你就能够关注其他服务上的更新，并在更新时获得通知。这样一来，就有大量的整合场景成为可能。你将能够与其他的服务进行交互、在变更时获得通知、并进行相应的操作。这种整合可以包括任何形式，例如在 Dropbox 中上传了某个新文件、在 Trello 中新建了一个 Issue、或是通过 PayPal 进行了一次支付操作。随着 WebHooks 的应用不断增多，这种应用场景也将产生指数级的增长。
- 虽说这一模式本身并不复杂，但还是有一些基本的规则需要处理。包括安全模型、数据格式、以及基于这一基本模式的各种变体。麻烦的地方在于，目前大多数的 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 平台上。
评论