ユースケース

あなたのAPIを壊す わざと。

任意のクライアントをプロキシに向け、500エラーをモックしたり、リクエストを途中で一時停止したり、実際に起きたことをそのままHARとしてエクスポートしてチームメイトに渡せます。

An Android phone, a browser and a backend server stream traffic into a central proxy hexagon on port 8888; one stream passes a block-and-script rule gate and comes out transformed, then one live stream flows on into a dashboard feed with green status codes. A globe marks upstream proxy routing. android browser server {} rules :8888 upstream live 200 201 200

課題

APIバグを再現するには バックエンドを偽装すること

遅いエンドポイント、不正な形式のエラー本文、2つの呼び出し間の競合状態——これらはどれも実サーバーから狙って発生させるのが困難です。

APIクライアント(モバイルアプリ、フロントエンド、CLI、CIジョブなど)を構築・テストするバックエンド/フルスタックエンジニア向け——SDKが返すレスポンスだけでなく、通信上の正確なバイト列を確認・制御する必要がある方に。

Busymateのproxy-serverは、あなたのクライアントと実際のAPIの間に位置します。すべてのリクエストがライブでキャプチャされ、iOSやChromeキャプチャと同じブロック/モック/ドロップのルールエンジンがここでも動作します——バックエンドに触れることなく、実際のリクエストに定型応答で答えたり、完全にドロップしたりできます。

解決方法

PAC URLひとつで、 その裏にはツールキット一式

SDKもインストールするエージェントも不要——プロキシに向けられるクライアントなら、それだけですでに統合完了です。

通信線上でモック・ブロック・ドロップ

リクエストが実際のAPIに届く前に、プロキシ自体でインラインに動くルールを使って、一致するリクエストに独自のステータス・ヘッダー・本文で応答するか、あるいはドロップします。

ブレークポイント→編集→再送信

リクエストを途中で一時停止し、生のHTTPを手動で編集してから続行または再送信——テストコードを1行も書かずに競合状態や不正なペイロードを再現できます。

HARエクスポート、またはREST経由でアクセス

チームメイトへの共有やバグ報告用に、正確なやり取りをHARファイルとしてエクスポートするか、シンプルなPostgRESTベースのREST APIで同じキャプチャデータにアクセスできます——どちらもSDKは不要です。

関連するサーフェス
  • Proxy
  • Dashboard
  • REST
  • MCP

手順

不安定なクライアントから 再現可能なバグ報告まで

どちら側もコード変更は不要です。

  1. 01

    クライアントをプロキシに向ける

    クライアント(スマホ、ブラウザ、バックエンドサービス、CIジョブなど)を、たった一つのPAC自動設定URLから構成します。トラフィックはすぐに流れ始めます。

  2. 02

    障害を再現する

    必要な壊れたレスポンスを返すようエンドポイントをモックするか、ブレークポイントを設定して実際のリクエストやレスポンスを続行前に手動で編集します。

  3. 03

    結果をエクスポートまたはクエリする

    バグ報告に添付するためにやり取りをHARとしてエクスポートするか、同じキャプチャエントリをテストスイートからREST API経由で取得します。

プロキシ上で

仕組み: ワイヤ上で

クライアントと本物の API の間にプロキシが一つ入り、その内部でルールが動きます。

  1. 01

    クライアントをプロキシに向ける

    各デバイスは固有のプロキシ ID とプロキシ自動設定 URL を持ちます。その URL をスマートフォンの Wi-Fi 設定、ブラウザのプロファイル、あるいはバックエンドや CI ジョブが読む HTTP プロキシ変数に貼り付けると、そのリクエストはすぐにダッシュボードのフィードに現れます。

  2. 02

    ルールを書くか、リクエストを一時停止する

    エントリを開いて、次回どうするかを選びます。独自のステータス・ヘッダー・ボディで応答する、破棄する、あるいはブレークポイントを設定して次に一致するリクエストを途中で止める。生のリクエストやレスポンスを手で編集してから、続行するか再送します。

  3. 03

    やり取りを他の人に渡す

    リクエストとレスポンスをバグレポート用に HAR ファイルとしてエクスポートするか、同じキャプチャ済みエントリをテストスイートから REST API 経由で読み取ります。どちらも SDK の解釈ではなく、ワイヤを実際に流れたバイトそのものです。

FAQ

クライアントを向ける前の よくある質問

クライアントに SDK やコード変更は必要ですか?

いいえ。HTTP プロキシに向けられるものはすべてすでに統合済みです。スマートフォン、ブラウザ、バックエンドサービス、CI ジョブ。キャプチャとルールはプロキシが処理し、クライアントは本物の API だと思っている相手と話し続けます。

1 つのエンドポイントだけモックして、残りは本物のままにできますか?

はい。ルールはホストとパスのパターンで一致するため、1 つのエンドポイントに用意した 500 を返させながら、他のリクエストはすべて本物のバックエンドへそのまま通せます。

ブレークポイントは他のトラフィックを止めますか?

いいえ。一致したリクエストだけが止まり、それ以外はすべて流れ続けます。準備ができたら続行・編集・再送すれば、クライアントにはサーバーが応答したのと同じように結果が見えます。

テストからキャプチャしたトラフィックを読めますか?

はい。キャプチャ済みエントリはシンプルな REST API から取得できるため、統合テストはモックの期待値ではなく、クライアントが実際に送った内容をアサートできます。

バックエンドを偽装するのはやめよう—— 本物の通信線を制御しよう

最初のクライアントをプロキシに向け、数分で最初のリクエストをモック・破壊・再送信できます。

Ask your mate