ApiCatcher コア機能の紹介と利用シーン

ApiCatcher は iOS、Android、macOS、Windows 向けの HTTP/HTTPS キャプチャ・デバッグツールです。スマホでは端末内の VPN で通信を引き取るので、パソコンをプロキシにする必要はありません。デスクトップではシステムプロキシと TUN を切り替えられます。TUN は、システムプロキシを見ないアプリを掴むためのモードです。

名前の Api は、最初に解きたかったことに由来します。キャプチャしたリクエストを履歴の一行で終わらせず、あとから使える API にすることです。ここでは 8 つの機能について、それぞれ何を解決するのか、対応する利用シーンを書きます。

キャプチャ

ここがすべての入口です。開始すると、アプリやブラウザの HTTP/HTTPS はローカルプロキシを通ります。CA 証明書をインストールして信頼すれば、HTTPS の中身が読めます。WebSocket のハンドシェイクとフレームも残り、フレームはチャットのように並びます。JSON は色分けされ、ペイロードでも検索できます。

あわせて使うもの:

• 許可リストと拒否リスト: Host で絞ります。許可リストに何か入っていると、一致した Host だけが残ります。拒否リストの Host は記録しません。* が使えます。例は *.example-api.com です。
• セッション: 開始から停止までが 1 セッションです。履歴をその回だけに限ったり、その回ごと削除したりできます。
• 検索: URL、リクエストヘッダ、レスポンスヘッダ、リクエスト Body、レスポンス Body を検索できます。メソッド、プロトコル、Content-Type、ステータスコード、期間でも絞れます。
• 書き出し: 1 件は Raw、cURL、Markdown に。まとめて HAR にも出せます。画像、動画、音声は種類ごとに分かれ、Range の断片は結合してから書き出します。

利用シーン：API 問題の切り分け。 失敗した操作をもう一度行い、履歴でそのリクエストを開きます。クライアントが実際に送った URL、Header、Body と、サーバーが返したステータスと Body を突き合わせます。リクエストがおかしいならクライアント側、リクエストは正しくレスポンスがおかしいならサーバー側です。どちらなのかを先に決めてから、先を調べます。

利用シーン：機能が使う API の確認。 その機能を、異なる業務シーンごとに操作します。履歴を見れば、当たった API と、パターンごとにパラメータがどう違うかが分かります。

API ドキュメントの自動生成

条件に合う HTTP/HTTPS は、Host ごとの API ドキュメントになります。API の識別は「メソッド + Host + Path」です。同じ API を何度キャプチャしても、Query、Header、Body は まだ出ていないフィールドだけ追加 します。すでにあるフィールド名は、あとから上書きしません。レスポンス例が更新されるのは、ステータスが 200 のときだけです。

Host 単位、API 1 件、または API のお気に入りから書き出せます。行き先は Postman、Apifox、または Bruno の ZIP です。

利用シーン：API 管理ツールへのエクスポート。 ドキュメントができたら、Host ごと、API 1 件、またはお気に入りのフォルダを Postman、Apifox、Bruno に渡し、そこで直して共有します。

HAR を書き出して Postman などに取り込んで API を作る方法とは違い、ApiCatcher が生成する API ドキュメントは、キャプチャが業務シーンを広く覆うほどフィールドが増え、より網羅されていきます。

リプレイ

リプレイは、ApiCatcher がもう一度クライアントになる機能です。履歴から HTTP/HTTPS を 1 件取り、必要ならクエリ、ヘッダ、Body を変えてサーバーへ送り、リプレイ画面でステータスとレスポンスを見ます。この送信でアプリの画面が更新されることはありません。WebSocket はここで再接続し、フレームを手で送って相手の返答を見ます。

キャプチャ中のリプレイはローカルプロキシを通るので、設定済みの Rewrite とスクリプトがかかり、履歴にも再び残ります。

利用シーン：API 連携。 バックエンドが API を直したあと、または調査用のログを足したあと、さっきキャプチャしたリクエストをワンタップで送り直します。1 回で直ったかどうかが分かり、そのリクエストを新しいログにも通せます。

コンボリプレイ

複数の HTTP/HTTPS をキャンバスに並べ、依存関係に沿って実行します。互いに依存しないノードは並列です。依存があるノードは直列で、前の段がすべて成功してから次の段に進みます。

よく使う編集は 4 つです。

利用シーン：呼び出しチェーンの連携。 後ろのリクエストは、前のレスポンスを使います。下流に依存を付け、上流のレスポンスを下流へ注入し、その順で実行します。たとえば GET /user は POST /login に依存し、POST /order は GET /user に依存します。後ろの 2 つでは token を Authorization に入れ、ログイン、ユーザー情報、注文の順で走ります。

利用シーン：同一 API・複数の入力。 そのリクエストを複数回追加します。順番に走らせたいときは、ノードを一本の線でつなぎます。依存だけ付け、注入は設定しません。各ノードの Body は事前設定で変えます。終わったら結果を比べます。たとえばログインを 3 回追加し、Body は正常なアカウント、誤ったパスワード、空のパスワードにします。

Rewrite

リクエストが業務サーバーに届く前、またはレスポンスがアプリに戻る前に、ルールで通信を変えます。ルールは対象範囲と動作です。範囲は Host で、Path と Method は任意です。

動作:

• リダイレクト: 本番のドメインを自分のマシンやステージングへ向ける。
• Mock: 本物のリクエストを出さず、決めたステータス、ヘッダ、Body を返す。
• リクエスト破棄 / レスポンス破棄: 送信できない状態、またはサーバーが返さない状態を再現する。
• 遅延: レスポンスを遅らせ、弱い回線でのローディングやタイムアウトを見る。
• 変更: ヘッダを直し、Body を丸ごと差し替え、または正規表現で Body の一部を置き換える。正規表現は、やりたいことを文章で伝えると AI が書けます。

利用シーン：API の Mock。 バックエンドがまだない、またはクライアントを特定の状態に進めたいときに、本物のリクエストを出さず決めたステータスと Body を返します。たとえば注文一覧に未払いと完了の 2 状態を返し、画面を先に作り、API ができたらルールを止めます。

利用シーン：レスポンスの書き換え。 一部のフィールドだけ変え、クライアントがそのあとどう動くかを見ます。サーバーのデータは触りません。たとえば正規表現で "balance": 100 を "balance": 0 にし、残高不足のときボタンがどう暗くなるかを見ます。

スクリプト

毎回値が変わる処理は、固定のルールでは足りません。JavaScript を使います。一致したリクエストは interceptRequest に、レスポンスは interceptResponse に入ります。自分で書いても、AI に書かせても、チームで配る LAN 上のスクリプト URL を指定しても構いません。

スクリプトから直接使えます。

• crypto: MD5、SHA、HMAC、Base64。署名や Body の暗号化・復号に使います。
• localStore: リクエストをまたいで Token などの状態を保持します。
• httpClient: スクリプトの中から別の HTTP を送ります。Token が切れたら先にログインしてから付ける、といった使い方です。

利用シーン：リクエストの動的計算。 署名やタイムスタンプは毎回違うので、決まった文字列の置換では追えません。そのリクエストの内容で計算してから通します。たとえばリプレイがいつも 401 なら、現在時刻と Body で HMAC を作り、X-Timestamp と X-Signature に書き戻します。リプレイの前にキャプチャを開始していないと、スクリプトはこのリクエストにかかりません。キャプチャが止まっていれば、スクリプトは実行されません。

利用シーン：Body の暗号化と復号。 社内のシステムでは、Body をもう一段暗号化していることがよくあります。HTTPS を解いても、見えるのは暗号文です。送る前に暗号化し、戻ってきたあと復号すれば、平文を読んで直せます。たとえば interceptResponse でレスポンス Body を復号して読み、リプレイでは interceptRequest で直した平文を再び暗号化して送ります。リプレイの前にキャプチャを開始しないと、スクリプトは実行されません。

DNS のすり替え

製品上の名前は DNS マッピング です。プロキシの層で DNS をすり替えます。システムの hosts も、Wi-Fi の DNS も変えません。キャプチャ中、ルールに一致した接続は公開 DNS を通さず、指定した IP へ直接 TCP を張ります。HTTP の Host と TLS の SNI は元のドメインのままなので、アプリ側は気づきません。*.apicatcher.net のようなワイルドカードも使えます。

利用シーン：同一ドメインでテスト／ステージング。 テスト、ステージング、本番は同じドメインです。テストやステージングへ行くには、そのドメインの向き先を変えます。DNS マッピングでテスト用またはステージング用の IP を指定すると、キャプチャ開始とともに有効になります。Wi-Fi の DNS をそのたびに変えなくてよく、システムの DNS キャッシュにも邪魔されません。

スケジュール実行

1 件のリプレイ、またはコンボリプレイ全体を、決めたタイミングで実行します。スケジュールは 2 種類です。

• Cron: 6 フィールドで、順に「秒 分 時 日 月 曜日」です。0 * * * * ? は毎分 0 秒です。書き方に自信がなければ、やりたいことを文章にして AI に作らせます。
• カスタム: 秒間隔で繰り返し、回数または継続する分数を制限できます。

自動停止の条件に当たるとタスクは止まります。実行履歴では所要時間と成功率が見えます。スマホでは先にキャプチャを開始しないとタスクは走りません。デスクトップはアプリが開いていれば走ります。

利用シーン：定時送信。 押せる時間が短く、手でクリックすると外れやすい。1 件のリクエスト、またはコンボリプレイを間隔を空けて自動で送り、レスポンスの内容で止めます。たとえばセール開始の数秒前から、1 秒ごとに注文を送り、code が 200 になるか、Body に購入成功やセール終了が出たら止めます。

利用シーン：定期ヘルスチェック。 同じ API を周期的に呼び、落ちていないか、遅くなっていないかを見ます。ヘルスチェックなら Cron 0 * * * * ? で毎分 1 回です。自動停止は付けず、実行履歴の P95 を見ます。

利用シーン：定期リグレッション。 組んであるコンボリプレイを計画どおり繰り返し、結果がまだ期待どおりかを見ます。コンボリプレイで同じ API を複数回追加し、ノードごとに違う入力を事前設定します。そのノードがテストケースです。このコンボを週 1 回実行します。先にログインが必要な場合は、ログインを 1 件だけ追加し、ほかのすべてのリクエストの共通の前段にします。ログイン以外のリクエスト同士は並列にしかなりません。

手順の詳細はドキュメントにあります。ユーザーマニュアル、Rewrite、スクリプト、コンボリプレイ、スケジュール実行。

ここで触れた機能が ApiCatcher のすべてではありません。ほかの機能は公式サイトで確認できます。本文の利用シーンは、これらの機能が使える場面を限定したものでもなく、各機能を用意したとき最初に解決したかった課題を例として挙げたものです。