はじめに
Webhookとは何かを整理します。
Webhookはイベントを通知する仕組み
Webhookは、あるシステムでイベントが発生したときに、別のシステムへHTTPリクエストを送る仕組みです。
例えば、
- GitHubでPushされた
- Stripeで決済が完了した
- Slackにメッセージが投稿された
といった出来事をきっかけに通知を送ることができます。
APIとの違い
Webhookを理解するうえで、APIとの違いを知っておくと分かりやすくなります。
APIは、必要な情報を取得するために自分からリクエストを送ります。
例えば、
ユーザー情報が欲しい
↓
APIを呼び出す
↓
結果を受け取る
という流れです。
一方でWebhookは逆です。
イベント発生
↓
Webhook送信
↓
通知を受け取る
となります。
そのため、
「情報を取りに行く」のがAPI、
「イベントを通知してもらう」のがWebhook
と考えるとイメージしやすいです。
なぜWebhookが使われるのか
Webhookがない場合、イベントが発生したかどうかを定期的に確認する必要があります。
例えば決済サービスの状態を確認する場合、
決済完了した？
↓
まだ
↓
決済完了した？
↓
まだ
↓
決済完了した？
↓
完了
のように何度も問い合わせることになります。
この方法はポーリング（Polling）と呼ばれます。
Webhookを利用すると、
決済完了
↓
決済サービス
↓
通知
↓
自分のシステム
となるため、定期的な確認が不要になります。
Webhookの利用例
Webhookは様々なサービスで利用されています。
GitHubでは、PushやPull Requestの作成を通知できます。
その通知をきっかけにCIを実行することもできます。
また、決済サービスでは決済完了の通知を受け取り、注文確定やメール送信を行うことがあります。
例えば、
決済成功
↓
Webhook受信
↓
注文確定
↓
メール送信
のような流れです。
Webhookはシステム同士を連携させるための入口として利用されることが多くあります。
Webhookを受け取る仕組み
Webhookを利用するには、通知を受け取るためのURLを用意します。
例えば、
https://example.com/webhooks/stripe
のようなURLです。
イベントが発生すると、サービス側はそのURLへHTTPリクエストを送信します。
受信したアプリケーションは、送られてきたデータを処理します。
HMACによる署名検証
Webhookを実装する際によく登場するのがHMACです。
WebhookはHTTPリクエストなので、第三者が偽装して送信する可能性があります。
そのため、多くのサービスでは署名付きでWebhookを送信します。
受信側は、
受信したデータ
+
共有秘密鍵
からHMACを計算し、送られてきた署名と比較します。
一致すれば、
- 正しい送信元から送られてきた
- 途中で改ざんされていない
ことを確認できます。
Webhookを実装するときの注意点
Webhookは必ず届くとは限りません。
ネットワーク障害やサーバー障害によって受信できない場合があります。
そのため、
- リトライに対応する
- 同じイベントを複数回受け取っても問題ないようにする
- イベントIDを利用して重複処理を防ぐ
といった設計がよく行われます。
特に決済処理では重要なポイントです。
おわりに
Webhookは、イベントが発生したことを別のシステムへ通知するための仕組みです。
GitHubやStripeをはじめ、多くのサービスで利用されており、システム連携の基盤として使われています。
APIとの違いや署名検証の仕組みも合わせて理解しておくと、実装を読む際にも役立ちます。