正如消息队列能够让同一个组织内的多个应用相互通信一样， WebHooks也为来自不同组织的网站提供了一种以异步的形式进行通信的方法。
\u0026#xD;\n\u0026#xD;\n从本质上说，WebHook就是一种回调机制。用户可以在WebHook提供者中注册一个自定义的URL，提供者将在适当的时机通过这个URL将相关的事件以消息的方式发送给应用。比方说，用户可以对Dropbox进行配置，当某个公司的Dropbox帐户中添加了一个新文件时，同时向该公司的审计与备份基础设施发出一条通知。
\u0026#xD;\n\u0026#xD;\n虽然从理论上说，这些功能完全有可能实现，但在现实世界中往往需要考虑到各种其他因素。如果忽视了这些因素，则恶意用户可利用这种基础设施发起拒绝攻击服务，正如pingback曾经出现过的漏洞一样。
\u0026#xD;\n\u0026#xD;\n为了防止发生这方面的安全问题，WebHooks设计了一个验证步骤。Dropbox的文档中是这样写的：
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n当你输入WebHooks URI时，就会自动向该URI发送一个初始的“验证请求”。验证过程使用了一个HTTP GET请求，其中带有一个名为challenge的查询参数。而你的应用在对该请求的响应中也需要包含这个challenge参数。这个验证过程请求的目的是确保你的应用确实希望通过该URI获取通知信息。即使你无意中输入了错误的URI（或者有人试图恶意地将你的服务器设置为他的WebHook），由于你的应用无法正确地响应challenge请求，因此Dropbox仍然不会向该URI发送任何通知。
\u0026#xD;\n
接收
\u0026#xD;\n\u0026#xD;\n在RC 1版本中，ASP.NET WebHooks包含支持以下提供商的自定义“接收者”：
\u0026#xD;\n\u0026#xD;\n- Azure Alerts与Kudu\u0026#xD;\n\u0026#xD;\n
- BitBucket\u0026#xD;\n\u0026#xD;\n
- Microsoft Dynamics CRM\u0026#xD;\n\u0026#xD;\n
- Dropbox\u0026#xD;\n\u0026#xD;\n
- GitHub\u0026#xD;\n\u0026#xD;\n
- Instagram\u0026#xD;\n\u0026#xD;\n
- MailChimp\u0026#xD;\n\u0026#xD;\n
- PayPal\u0026#xD;\n\u0026#xD;\n
- Pusher\u0026#xD;\n\u0026#xD;\n
- Salesforce\u0026#xD;\n\u0026#xD;\n
- Slack\u0026#xD;\n\u0026#xD;\n
- Stripe\u0026#xD;\n\u0026#xD;\n
- Trello\u0026#xD;\n\u0026#xD;\n
- WordPress\u0026#xD;\n\u0026#xD;\n
- IFTTT与Zapier\u0026#xD;\n
同时，新版本还提供了一个通用的框架库，可用于创建用户自定义的接收者。但用户必须将该接收者托管在公有的网站上，否则提供者将无法连接到这些接收者。
\u0026#xD;\n\u0026#xD;\n提供
\u0026#xD;\n\u0026#xD;\nASP.NET还提供了一套框架，允许用户提供自己的WebHooks，让其他应用程序使用。这套框架包括两个部分，一是WebHooks基础设施本身，二是WebHooks注册信息的存储机制。目前可直接使用的存储机制包括SQL Server和Azure Table Storage。
\u0026#xD;\n\u0026#xD;\n读者可以在.NET Web Development and Tools博客上获取完整的教程与示例。同时可以在GitHub找到项目的源代码，项目本身遵循Apache 2授权协议。目前的发布候选版本需要ASP.NET MVC 5和WebAPI 2的支持。
\u0026#xD;\n\u0026#xD;\n查看英文原文：ASP.NET WebHooks RC 1
