ひとことで言うと
Webhookは、相手側で出来事が起きたときに、あらかじめ登録したURLへ自動で知らせてもらう仕組みです。 こちらから何度も「変化あった？」と聞きに行くのではなく、「起きたらこの連絡先へ知らせてください」と折り返し先を渡しておくイメージです。 HTTP で通知を受ける連携の入口として、決済通知やフォーム送信、デプロイ完了の連絡などでよく出てきます。
たとえ話でもう少し詳しく
Webhookは、お店で「準備できたらこの番号へ電話してください」と連絡先を預けておくのに似ています。
- こちらから何度も店に電話して確認しなくてよい
- 店側で準備ができたら、預かっていた連絡先へ知らせてくれる
- 受け取る側は、その連絡が本当に店から来たのか確かめる必要がある
システムの世界でも同じです。 たとえば決済完了、フォーム送信、在庫変化、デプロイ完了のような出来事が起きたとき、サービス側が指定されたURLへHTTPリクエストを送り、受け取り側へ知らせます。 その結果、別のシステムがすぐ次の処理を始めやすくなります。
よく出る場面・使いどころ
- 決済サービスで、支払い完了を自社システムへ知らせたいとき
- フォーム送信後に、社内チャットや管理表へ自動反映したいとき
- Git の push やデプロイ完了をきっかけに別処理を動かしたいとき
- 外部サービスで起きた更新を、なるべく早く自分のアプリへ取り込みたいとき
似た言葉との違い
- API
- こちらから必要なときに問い合わせに行く窓口
- Webhook は、相手側で出来事が起きたときに向こうから知らせてくる仕組み
- ポーリング
- 変化があったかを定期的に聞きに行く方法
- Webhook は、起きた瞬間だけ通知が飛んでくる
- メール通知
- 人が読むための連絡
- Webhook は、別のシステムが自動処理を始めるための連絡
実務で気にするポイント
- 通知を受けるURLは、外部から呼ばれる前提で安全に作る
- 署名や共有秘密で、送信元が本物か確認する
- 同じ通知が再送されても困らないよう、重複処理に強くする
- 受信失敗時の再試行やログ確認の流れを用意する
注意: Webhookは「自動で知らせる仕組み」ですが、必ず1回だけ、必ず順番通り届くとは限りません。受け取り側で本人確認、重複対策、失敗時の再処理を考えておくことが大事です。