Webをデバッグする
この記事では、Caché Webアプリケーション（主にREST）のテストとデバッグを外部ツールを用いて行うことについて説明します。 パート2では、Cachéツールの使用について説明します。
サーバー側のコードを作成したのでクライアントからテストしたい、またはすでにWebアプリケーションが存在するが機能していない― そういったときに使用できるのがデバッグです。 この記事では、最も使いやすいツール（ブラウザ）から最も包括的なツール（パケットアナライザー）までを説明しますが、まずは、最も一般的なエラーとその解決方法について少し説明します。
エラー
401 Unauthorized
これは、本番環境へのデプロイ中に最も頻繁に発生するエラーだと思います。 ローカル開発サーバーには通常、最小限のセキュリティ設定か、バニラを除く通常セキュリティ設定が構成されています。 一方の本番サーバーには、より制限的なスキームが適用されます。 つまり、以下を確認してください。
- ログイン済みであること
- アクセスするdatabase/table/procedure/row/columnへのアクセス権があること
- 許可されていないユーザーがOPTIONSリクエストを実行できること
404 Not Found
以下を確認してください。
- URLが正しいこと
- 新しいアプリケーションであり、外部Webサーバーを使用している場合は、Webサーバーをリロードしてください。
アプリケーションエラー
最も簡単に見つけるには、スタックトレースを使用できます。 解決策は、完全にアプリケーション固有です。
デバッグツール
Webブラウザ
必ず最初に利用できるデバッグツールはWebブラウザです。Chromeが推奨されますが、Firefoxでも十分にデバッグできます。 GETリクエストについては、URLをアドレスバーに入力すればテストできますが、その他すべてのリクエストには、Webアプリケーションかjsコードの記述が必要です。 一般的には以下のように行います。
- F12キーを押して、デベロッパーツールを開きます。
- ［Network］タブに移動します。
- ［Preserve Log］チェックボックスがオンになっていない場合は、それをオンにします。
- XHRリクエストのみを表示します。
- Webアプリケーションでバグのあるアクションを実行します。
ここから、リクエストを調べて再送信できます。 Firefoxでは、リクエストを繰り返す前にリクエストを編集することも可能です。
メリット:
- いつでも利用可能
- 使いやすい（エンドユーザーは［Network］と［Console］タブのスクリーンショットを送信できます）
- エンドユーザー環境
デメリット:
- 部分送信/破損などのレスポンスを表示しない
- 大規模なレスポンスでは速度が低下する
- 大量のレスポンスでは速度が低下する
- すべて手動で行われる
RESTクライアント
RESTクライアントは、Webアプリケーションのテスト向けに特別に作成されたスタンドアロンのWebアプリケーションまたはWebブラウザアドオンです。 私はPostmanを使用していますが、似たようなものはたくさん存在します。 Postmanでのデバッグは次のようになります。
Postmanはリクエストをコレクションにグループ化して処理します。 リクエストは環境に送信可能です。 環境は変数のコレクションです。 たとえば、私のCACHE@localhost環境ホスト変数は、localhostに設定されており、userは_SYSTEMに設定されています。 リクエストが送信される際は、変数は選択した環境の値に置き換えられてリクエストが送信されます。
MDX2JSONプロジェクトのサンプルのcollectionとenvironmentはこちらにあります。
メリット:
- 一度作成すれば、どこででも使用できる
- リクエストの制御に優れている
- レスポンスの「Pretty」表示
デメリット:
- 連鎖リクエスト（request1に対するレスポンスがrequest2またはrequest2Bを強制できる）のデバッグは依然として手動
- 部分送信/破損などのレスポンスに失敗することがある
HTTPデバッグプロキシ
HTTP(S) トラフィックをログに記録するスタンドアロンアプリケーション。 ログに記録されたリクエストを変更して再送信することができます。 私はCharlesとFiddlerを使用しています。
メリット:
- 部分送信/破損などのレスポンスを処理する
- レスポンスの「Pretty」表示
- HTTPSトラフィックのサポートに優れている（パケットアナライザーより）
- キャプチャセッションを保存できる
デメリット:
- リクエストを送信するために何か（Webアプリケーション/RESTクライアント/JSコード）が必要
パケットアナライザー
ネットワークを通過するトラフィックを傍受してログに記録できるコンピュータープログラム。 データストリームがネットワークを流れる際に、スニファーが各パケットをキャプチャし、必要に応じてパケットの生データをデコードします。 これが最も包括的なオプションですが、適切に動作させるには、ある程度のスキルも必要となります。 私はWireSharkを使用しています。 以下にインストールと使用方法を簡単に説明します。
- ローカルパケットをキャプチャする場合は、ループバックについて読み、前提条件のソフトウェア（Windows用npcap）をインストールします。
- WireSharkをインストールします。
- キャプチャフィルタを構成します（たとえば57772のトラフィックのみをキャプチャするファイルはport 57772とします）。
- キャプチャを開始します。
- 表示フィルタを構成します（たとえば特定のIPへのhttpトラフィックのみを表示する場合は、ip.addr == 1.2.3.4 && httpとします）。
以下は、ポート57772（キャプチャフィルタ）のhttpトラフィック（表示フィルタ）をキャプチャした例です。
メリット:
- 部分送信/破損などのレスポンスを処理する
- 大量のトラフィックをキャプチャできる
- 何でもキャプチャできる
- キャプチャセッションを保存できる
デメリット:
- リクエストを送信するために何か（Webアプリケーション/RESTクライアント/JSコード）が必要
どれを使用するか
それは目的によって異なります。 まず、リクエストをログに記録する（デバッグプロキシ、パケットアナライザー）かリクエストを生成（ブラウザ、RESTクライアント）することを目的とすることができます。
REST Web APIを開発している場合は、RESTクライアントを使用するのが、動作をテストする最速の方法です。
ただし、RESTクライアントからのリクエストが機能してもクライアントWebアプリケーションが機能しない場合は、httpデバッグプロキシとパケットアナライザーが必要となることがあります。
クライアントがあり、サーバー側APIを開発してそれを操作する場合は、httpデバッグプロキシかパケットアナライザーが必要となります。
4種類すべてのツールを理解し、使用中のものが作業に不十分となった場合に素早く切り替えられるようにしておくことをお勧めします。
適切なツールが明確である場合もあります。
私は最近、人気のあるhttp拡張プロトコル用のサーバー側APIを開発しましたが、その際の要件は次のとおりでした。
- クライアントがすでに作成済みであり、コードを変更できない。
- クライアントごとに動作が異なる。
- httpとhttpsでの動作が異なる。
- 認証タイプごとに動作が異なる。
- クライアントごとの1秒当たりのリクエスト数は最大100件である。
- 全員がRFCを無視する。
この要件で使用できるソリューションは1つしかありません。パケットアナライザーです。
または、JS消費用のREST APIを開発しているのであれば、テストに最適なツールはRESTクライアントです。
Webアプリケーションをデバッグする場合は、Webブラウザでデバッグを開始しましょう。
パート2では、Webデバッグに関してCaché側でできること（たくさんあります）について説明します。
皆さんは、クライアント側通信をデバッグする際にどのようなアプローチを採用していますか？