WebhookがAPIを一変させた：問い合わせるのではなく、出来事が起きたときにアプリが呼び出される

2007年当時、ウェブサイトにはAPIがあったが、連携といえば依然としてポーリングだった。あるアプリケーションが別のアプリケーションの扉を何度もノックし、何か新しいことが起きたかを尋ねていた。Jeff Lindsayのブログ記事「Web hooks to revolutionize the web」は、Unixのパイプの考え方——単純なプログラムが入出力を通じて連鎖する——をウェブに応用し、サイトがコールバックを登録し、イベントが発生したときに他のサイトがそれを呼び出すことを提唱した。

その設計は小ささゆえにラディカルである。webhookとはユーザー定義のHTTPコールバックである。発信元のアプリにURLを渡すと、イベントが発火したときにそのアプリがデータをPOSTしてくる。メッセージブローカーも、新しいワイヤーフォーマットも、新しいポートや証明書も不要で、誰もがすでに動かしているウェブ上のリクエストだけで済む。各連携は1対1なので、中央のコーディネーターなしにネットワークが複利的に広がっていく。

このパターンはプラットフォームごとに広がった。GitHub、Stripe、Shopify、Slackがwebhook対応を出荷し、2010年代までにはZapierのような連携プラットフォームが、アプリ同士が「話す」既定の方法として説明できるようになった。アプリケーションにとってのプッシュメールの瞬間であり、ソフトウェアが確認するのをやめて受信するようになったのだ。

こちらから電話しないでください——こちらから、平文のHTTPで電話します

webhookは1つのURLなので、どのアプリも新しいインフラなしに提供できる

プッシュはポーリングに勝る：無駄なリクエストがなく、既定でほぼリアルタイムの配信が得られる

平文のHTTPに乗るので、ファイアウォール、プロキシ、TLSがすでにそのまま機能する

1対1の接続が、中央のブローカーなしにネットワークへと複利的に広がる

最も安価な標準とは、新しい仕組みを必要としない標準である。新しいパターンを、誰もがすでに動かしているもの——URL、HTTP POST——で表現できれば、普及はひとりでに進む。

webhookは部外者のアイデアから参加の前提条件へと変わり、その単純さが独自の問題を生み、業界はそれに合わせて標準化を進めた。現在ではペイロードは署名され（StripeがHMAC署名を広めた）、利用側にはリトライと冪等性が必要となり、攻撃者が提供したURLを取得する受信側は、OWASPが詳細に文書化している古典的なサーバーサイドリクエストフォージェリの攻撃経路となった。1本のブログ記事から始まったものが、今では決済の確認、コードのデプロイ、チャットアプリの通知の仕組みになっている。