Webhook 翻轉了 API：應用程式不再主動詢問，而是在事件發生時被呼叫

2007 年時，網站已有 API，但整合仍意味著輪詢：一個應用程式反覆上門詢問另一個應用程式是否有新事件發生。Jeff Lindsay 的部落格文章〈Web hooks to revolutionize the web〉主張把 Unix 管線的概念套用到網路上——讓簡單的程式透過輸入與輸出串接起來——做法是讓網站註冊回呼，當事件發生時，由其他網站呼叫這些回呼。

這項設計的激進之處在於它極其簡單：webhook 就是使用者自訂的 HTTP 回呼。你把一個 URL 交給來源應用程式；當事件觸發時，它會把資料 POST 給你。不需要訊息代理程式，不需要新的傳輸格式，也不需要新的連接埠或憑證——只要透過大家早已在用的網路發送一個請求即可。每個整合都是一對一，因此整個網路無需任何中央協調者就能逐步擴展。

這個模式一個平台接一個平台地擴散。GitHub、Stripe、Shopify 和 Slack 都推出了 webhook 支援，到了 2010 年代，像 Zapier 這樣的整合平台已能把它描述為應用程式彼此「溝通」的預設方式——這是應用程式的推播電子郵件時刻，軟體從此不再主動查看，而是開始接收。

別打電話給我們——我們會透過純 HTTP 打給你

webhook 只是一個 URL，因此任何應用程式都能提供，無需新的基礎設施

推送勝過輪詢：沒有浪費的請求，預設就能近乎即時地送達

它走的是純 HTTP，因此防火牆、代理伺服器和 TLS 本來就能運作

一對一的連線無需中央代理程式就能串連成網路

最便宜的標準，就是不需要新機制的標準。如果你能用大家早已在用的東西——一個 URL、一個 HTTP POST——來表達新模式，採用自然會水到渠成。

webhook 從局外人的想法變成基本必備，而這份簡單也帶來了自身的問題，產業隨後圍繞這些問題制定了標準：酬載（payload）如今會加上簽章（Stripe 推廣了 HMAC 簽章），消費端需要重試與冪等性，而會去抓取攻擊者所提供 URL 的接收端，則成了典型的伺服器端請求偽造（SSRF）攻擊向量，OWASP 對此有詳盡記載。最初只是一篇部落格文章，如今已成為付款確認、程式碼部署和聊天應用程式通知的運作方式。