Webhookの仕組み ― ポーリングとの違いからセキュリティまで

いい連想だね！Webhookは「イベントが起きたらHTTPで通知してくれる仕組み」だよ。普通のAPIはこっちから聞きに行くけど、Webhookは相手から教えてくれる「逆方向のAPI」なんだ。電話で例えると、自分からかけるんじゃなくて、相手が用事があるときにかけてきてくれる感じだね。

それがポーリングだよ。「新しい注文ある？」「ない」「新しい注文ある？」「ない」…って定期的に聞き続けるんだ。無駄なリクエストが多くてサーバーに負荷がかかるし、リアルタイム性も低い。Webhookなら「注文が入ったよ！」ってすぐ教えてくれるから効率的なんだ。

まず受信側が「このURLに通知して」と登録するよ。たとえばGitHubで「pushされたら https://myapp.com/webhook に通知」と設定する。するとpushイベントが起きたとき、GitHubがそのURLにHTTP POSTでJSON形式のデータを送ってくれるんだ。

ペイロード（payload）って呼ばれるJSONデータで、イベントの種類や詳細が入ってるよ。GitHubなら「誰が」「どのブランチに」「何をpushしたか」、Stripeなら「どの顧客の」「いくらの決済が」「成功したか」みたいな情報だね。Slackの通知やCI/CDの自動起動にも使われてるよ。

いい質問！HMAC署名っていう仕組みで検証するよ。送信側と受信側で秘密のトークンを共有しておいて、送信側がペイロードからHMAC-SHA256のハッシュ値を計算してヘッダーに付ける。受信側も同じ計算をして、一致すれば「本物の通知だ」と分かるんだ。

多くのWebhook送信側はリトライ機能を持ってるよ。HTTPステータスが200以外だったら、指数バックオフ（1分後→5分後→30分後…）で再送するんだ。受信側は同じ通知が複数回届く可能性があるから、べき等性キー（idempotency key）で重複処理を防ぐ設計が大事だよ。

デッドレターキュー（DLQ）っていう仕組みを使うことがあるよ。何回リトライしても失敗した通知を専用のキューに溜めておいて、あとで原因を調査・再処理できるようにするんだ。本番環境では通知の取りこぼしが致命的になることもあるから、こういう設計が重要なんだよ。

WebSocketは双方向のリアルタイム通信で、チャットみたいに常時接続が必要な場面向き。SSE（Server-Sent Events）はサーバーからクライアントへの一方向ストリーム。Webhookはイベントごとに独立したHTTPリクエストで、接続を維持しなくていいのが特徴だよ。サーバー間の連携にはWebhookが一番シンプルで使いやすいんだ。

順序保証がないことは意識しておくべきだね。ネットワーク遅延やリトライで、イベントAの通知よりイベントBの通知が先に届くことがあるんだ。タイムスタンプやシーケンス番号で順序を判定する仕組みを入れておくと安心だよ。あと、受信エンドポイントは5秒以内にレスポンスを返して、重い処理は非同期で行うのがベストプラクティスだね。