Webhookを作るときのデバッグに役に立つものを作った

その名もWebhookDebugger 実はRailsのアプリケーションで15分位でシュッと書いたものを単機能だったのを、素のRackアプリケーションにして書き直したものである。

github.com

以下に簡単にこのアプリケーションについての機能を簡単に説明しておく。

基本はオウム返しをするだけのアプリケーションだが...

ロジックはすごい簡単で、GETで送るクエリパラメータやPOSTのform-dataないしはjsonをレスポンスに含めて返してくれるものである。 それだけだとただのオウム返しAPIでWebhookを作るときに何も便利にはならない。 そこで一工夫を凝らしてみることでWebhookを作るときに便利にしてみた。

1. どのパス、どのHTTPメソッドを指定してもリクエストを受ける取ることができる。

request.binなどの外部サービスでも良いのだけど、これは受け取る先のURLパスが決まってしまっている。 どのパスに送信するかというのをユニットテストレベルではなく、ちゃんと目で確認したいときに重宝するだろう。

  curl -XPOST http://localhost:9292/hoge/fuga | jq
  {
      "path": "/hoge/fuga",
      "request_method": "POST",
      "status_code": 200
  }

  curl http://localhost:9292/nick | jq
  {
      "path": "/nick",
      "response_status_code": 200,
      "request_method": "GET",
      "status_code": 200
  }

2. 任意のHTTPステータスコードを返させることができる

パラメータに response_status_codeというものが存在し、これに対して任意のHTTPステータスコードを設定することができる。 コレにより、5xx系のエラーレスポンスの場合はX分後に送信キューに再送処理を積む。他にも4xx系だったら再送処理無しで異常終了にする。あとは5回以上エラーになったら再送をやめる。 といったことの確認が簡単に出来るようになる。 以下のコードの場合、レスポンスのHTTPステータスコードが必ず401になるようになる。

  curl -XPOST http://localhost:9292/hoge/fuga?response_status_code=401 | jq
  {
      "path": "/hoge/fuga",
      "response_time": 1000,
      "response_status_code": 401,
      "request_method": "POST",
      "status_code": 200
  }

3. レスポンスの待機時間を設定することができる

パラメータに response_timeを設定することで、任意のミリ秒分だけ、レスポンスを返す時間を遅らせることができる。（waitで雑に設定しているだけなので、きっかり1秒とかではなく、ベストエフォートです。） コレによりサーバレスポンスに時間がかかってしまった場合、一旦失敗として扱って送信キューに再送処理を積む。といったことの確認が簡単になった。

  curl -XPOST http://localhost:9292/hoge/fuga?response_time=1000 | jq
 {
      "path": "/hoge/fuga",
      "response_time": 1000,
      "request_method": "POST",
      "status_code": 200
  }

以上の3つがあることで、 オウム返しによる、レスポンスでの送信内容にチェック、 エラー時のWebhookの再送機能やレスポンス待機時間によるエラーハンドリングなどが実現可能になった。

Webhook送信元のアプリケーションがdocker-composeで管理されている場合、Webhookの送信先として、このアプリケーションのコンテナを定義しておくのが良いと思う。

なかなかWebhook送信先のアプリケーションの実装について知識がないと、 こういうテストがなかなか難しかったり、送信先のアプリケーションの完成を待たないとちゃんとテストできないとかがありがちなのだけど、 このAPIを利用することでエラーケースのテストや再送のテストが用意になって、効率がグッと向上した。

どういったわけか、業務上Webhookを作る機会が何故か多かったし、 これからもWebhook処理も書く必要はかならずあるので、このAPIは今後も重宝することだろう。