Webhookとは？

この記事は What’s a Webhook? の抄訳です。

近年、Webhookという仕組みが徐々に知名度を上げています。イベント駆動のWeb上の処理が増えるにしたがって、Webhookを適用できる場面は広がってきています。

Webhookは、「Webコールバック」や「HTTPプッシュAPI」などとも呼ばれ、あるアプリケーションから別のアプリケーションに対して、リアルタイムな情報提供を実現するための仕組みです。複数端末で情報をやり取りするときによく使われる手法に「ポーリング」がありますが、ポーリングによってリアルタイムなやり取りを実現するためには、高い頻度でデータの有無を問い合わせる必要があります。それに対してWebhookは、イベント発生をトリガにして送信側がデータを送出するので、更新があるか確認するために受信側がリクエストを送り続ける必要が無く、送信側・受信側ともに効率のいい方法です。

唯一欠点があるとすれば、初期設定が難しいことです。Webhookは「リバースAPI」とも呼ばれるように、Webhookプロバイダ（リクエスト送信側）から提供されるAPI仕様に応じて、受信側のAPIを実装する必要があるためです。Webhookプロバイダは、指定されたURLに対してHTTPリクエスト（通常はPOST）を行い、受信側はその内容をパース（リクエストの内容を解釈）して利用します。

WebhookとAPIの違い

WebhookとAPIは、どちらもソフトウェアやアプリケーション同士で通信するために使用されますが、以下のように目的や使用方法が異なります。

	Webhook	API
トリガと通信方向	イベントが発生した際に自動でデータを「プッシュ」する	明示的なリクエストがあった場合に「プッシュ」「プル」両方向でデータを交換する
利用シーン	主にリアルタイム通知	データの取得・更新等
事前設定	受信側エンドポイントを構築し、データの通知先として送信側に設定しておく必要がある	事前設定は必要ない
セキュリティ	公開されたエンドポイントにデータをプッシュする仕組みであるため、セキュリティ対策が必要	多くの場合データアクセスのために認証が必要

WebhookとAPIのどちらを使用するかは、用途に合わせて考えるとよいでしょう。

Webhookの利点

Webhookには他にも以下のような利点があります。

• 自動化：Webhookの受信をトリガとして、関連する後続の処理を自動的に実行できます。例えばメルマガ新規登録があったというイベントを受信したら、登録者に自動でメールを送信するといったものです。
• 統合：異なるシステム同士をWebhookで連携させることで、アプリケーション間のデータ同期などがシームレスに行えます。
• 柔軟性：Webhookは送信するデータの形式に制約がありません。シンプルなJSONから複雑なXMLまで様々な形式に対応できます。
• セキュリティ：Webhookはイベント駆動であるため、不要な通信やリソースの浪費を防ぎ、セキュリティ上のリスクを軽減できます。また、イベントを特定のエンドポイントのみに送信するように設定可能できるため、データ漏洩などのリスクを抑えることができます。

Webhook利用にあたっての準備

Webhookの利用

Webhookを利用するための手順は以下の通りです。

1. Webhookプロバイダからのリクエストを受けるためのアプリケーションのURLを設定（設定画面やAPIを通じて行うことが多い）する
2. 受信側アプリケーションのURLがパブリックネットワークからアクセスできるようセットアップする

Webhookは通常、次のうちいずれかの方法でデータを送信します。

• JSON（一般的）もしくはXML（微妙……）
• フォームデータ（application/x-www-form-urlencodedもしくはmultipart/form-data）

どの方法でデータが送信されるかはプロバイダによって異なります（受信側で選択できる場合もあります）。いずれにせよ、通常はWebフレームワーク側がパースをしてくれます。Webフレームワークの機能でパースできない場合でも、ライブラリなどを利用すれば簡単にパースできます。

Webhookのデバッグ

Webhookは非同期処理のため、デバッグが難しい場合があります。トリガをひく→リクエストを待つ→レスポンスを確認する、といった流れが必要になるので、やり方によっては非常に効率が悪くなります。しかし、ラッキーなことにツールを使えば簡単にデバッグが可能です！ドキュメントでも紹介している方法を以下にまとめます。

1. RequestBinのようなWebhookのリクエストを収集するツールを利用して、Webhookがどういったリクエストを送信するか確認する
2. cURLやPostmanのようなツールを利用してテスト用のリクエストを生成する
3. ngrokのようなツールを利用してローカルマシン上でプログラムをテストする
4. Runscopeのようなツールを利用して全体のフローを確認する

Webhookをセキュアにする

Webhookを利用するには、受信側アプリケーションのURLをパブリックネットワークに公開する必要があるため、そのURLを見つけた第三者から不正なリクエストが送られてくる可能性があります。こういったことを防ぐためには、Webhookの送信元が正当であるかどうかの確認が必要です。最低限対応すべき内容としてTLS接続（https）の強制化がありますが、その上で、さらにセキュアにする方法をいくつかご紹介します。

1. Webhookプロバイダのリクエスト先URLに、`?auth=TK`のようなトークンをパラメータとして追加することで、一意に識別する（よく採用される方法です）
2. 受信側アプリケーションにBasic認証を設定しておき、Webhookプロバイダのリクエスト先URLに認証情報を含めることで認証を通すようにする（簡単で、かつよく採用される方法です）
3. Webhookプロバイダに各リクエストに署名してもらう（ほとんどの攻撃は最初の2つの方法で防ぐことができますが、リクエストにトークンや認証情報を追加して送信しなければなりません。一方、この方法は、正しい送信者からのリクエストであることを受信側で確かめることができますが、プロバイダ側が署名に対応している必要があります。）

Webhookの設定で重要なこと

Webhookの受信側アプリケーションを作成する際の注意点が5つあります。

• Webhookプロバイダがレスポンスをどのように扱うか理解してエラー処理を行う
  Webhookプロバイダは、受信側アプリケーションがリクエストを正常に受け取ったら、その後のことは気にかけません。これは、受信側アプリケーションでエラーが発生した場合、データを失うことを意味します。多くのWebhookは受信側のレスポンスをチェックしていますので、受信側アプリケーションがエラーを返せばリクエストは再送されます。逆に、受信側アプリケーションがリクエストを処理したにも関わらずエラーを返してしまうと、プロバイダからの再送によりデータが二重化してしまいます。
• 受信側アプリケーションが、想定しているスケールのリクエストを処理できることを確認する
  イベントが数多く発生した場合、多数のリクエスト（POST）が送られてきます。想定される規模のリクエストを受信側アプリケーションがきちんと処理しきれるか事前に確認しておきましょう。Loader.ioのような負荷テストツールを利用するのも有効です。
• Rate limit（レート制限）を設定する
  不正利用を防ぐためにレート制限を設定しましょう。これにより、リクエストが突然急増してもシステムが停止することはありません。
• ログを記録し、イベントを監視する
  Webhookイベントのログを保管し、監視しましょう。トラブルシューティングや受信リクエストの把握に役立ちます。
• ドキュメントを整備する
  他の開発者にWebhookを提供する場合は、わかりやすいドキュメントを用意しましょう。Webhookのセットアップ方法やデータ形式、さまざまなケースにおける処理内容など、Webhook機能全体を詳細に説明するものがよいでしょう。

はじめてみましょう

Webhookを真に理解するための最良の方法は実際に試してみることです。Twilio SendGridでは、Event Webhookを使ったメール到達の確認や、Inbound Parse Webhookを使ったメール受信の確認ができます。ぜひお試しください。