ASP.NET WebHooks成立的動機有兩方面

　　WebHooks為HTTP服務(wù)的整合提供了一種協(xié)議模式，從而能夠通過HTTP請求的形式建立一種非常簡單的事件通知模型。通過對某個Webhook的訂閱，你就能夠關(guān)注其他服務(wù)上的更新，并在更新時獲得通知。這樣一來，就有大量的整合場景成為可能。你將能夠與其他的服務(wù)進(jìn)行交互、在變更時獲得通知、并進(jìn)行相應(yīng)的操作。這種整合可以包括任何形式，例如在Dropbox中上傳了某個新文件、在Trello中新建了一個Issue、或是通過PayPal進(jìn)行了一次支付操作。隨著WebHooks的應(yīng)用不斷增多，這種應(yīng)用場景也將產(chǎn)生指數(shù)級的增長。

　　雖說這一模式本身并不復(fù)雜，但還是有一些基本的規(guī)則需要處理。包括安全模型、數(shù)據(jù)格式、以及基于這一基本模式的各種變體。麻煩的地方在于，目前大多數(shù)的Webhook提供者在處理這些基本規(guī)則時都存在著細(xì)微的差別。這種差別就像雪花一樣，雖然每片雪花看起來都很相似ASPCMS批量添加產(chǎn)品 ，但多多少少存在著一些特別之處。ASP.NET WebHooks的目的就是處理所有這些繁瑣的部分，提供一個統(tǒng)一的用戶模型，并讓用戶能夠快速開始進(jìn)行在服務(wù)間進(jìn)行整合的任務(wù)

　　InfoQ：Webhook除了HTTP之外并沒有其他任何確立的協(xié)議，那么在發(fā)送方是否會存在某些方面的限制因素？（作為接收者來說）ASP.NET WebHooks是否能夠自動兼容那些目前已經(jīng)提供Webhook的服務(wù)呢？

　　HN：我們已經(jīng)在項目中提供了針對各種服務(wù)的Webhook，例如Azure

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

　　MailChimp、PayPal、Pusher、Salesforce、Slack、Stripe、Trello，以及WordPress，不過要添加對其他提供者的支持也是很簡單的，并且所支持服務(wù)的名單還在不斷地增長中。事實上，對于Kudu和BitBucket的支持是來自于社區(qū)所提交的pull請求，我們也正在添加對更多的提供者的支持。