CSのTips一覧

画面で失敗したら、送った要求と返った応答をNetworkで見る

画面の見た目だけでは原因を絞れない。NetworkパネルでURL・メソッド・入力・HTTPステータス・応答を確認し、ブラウザーとAPIのどちらを次に調べるか決める。

用語

Networkパネル
ブラウザーが記録した要求と応答を確認する開発者ツールの画面。
HTTPステータス
応答の意味を示す番号。画面表示や業務処理全体の正しさまでは保証しない。
応答
要求に対して返るステータス・ヘッダー・本文などの情報。

図と例

画面の症状から、実際の送受信と画面処理をたどる

Networkを開いて操作を再現 → URL・メソッド・入力を確認 → ステータスと応答の内容を照合 → 証拠に応じてAPIか画面処理を調査

仮定の例：一覧APIは200でitemsに1件を返すが、画面は空。Networkで正しいURLと応答を確認したら、画面がitemsではなくdataを読んでいないか、絞り込みで消していないかを調べる。200だけを見て「画面も正しい」とは判断しない。

実際のサービス・製品では

  • Chrome DevTools

    NetworkではHTTPステータスや応答、要求を起こしたInitiatorを確認できる。要求がどこから発生したかをソースへたどれる。

    資料を読む

  • Fetch API / MDN

    fetchはHTTPエラーステータスでもResponseで成功するため、response.okやstatusをアプリ側で確認する例を示している。

    資料を読む

解説

画面とAPIの境界で、思い込みではなく送受信した内容を基に調べる。共有する記録からCookie・認証ヘッダー・個人情報を除く。調査のための再送でも、注文や送金などの副作用がある操作は検証環境で行う。

保存ボタンが動かないときは、開発者ツールのNetworkパネルを開いてから操作する。対象の要求が記録されたか、URLとメソッド、送信した入力、HTTPステータス、応答の内容を順に見る。記録されない場合は記録状態やフィルターも確かめる。応答があるなら、期待した要求だったかと内容を照合し、画面の処理へ進む。200でも別のデータを返していたり、応答の読み取りや描画に失敗したりする。JavaScriptのfetchは404や500だけではPromiseを失敗にしないため、response.okなどによる判定も必要。ステータスだけで原因や業務の成功は確定しない。

トレードオフ

ブラウザーで実際の送受信を見る
得るもの：画面が送った入力と受け取った内容を一緒に確認できる
払うもの：サーバー内部の処理を知るにはログなどとの照合が必要
検証用クライアントでAPIを直接呼ぶ
得るもの：画面処理を通さずAPIの挙動を確かめやすい
払うもの：ブラウザーの認証・ヘッダー・入力との違いをそろえる必要がある

さらに学ぶ

チェック

正しい一覧URLへの応答が200で、期待どおりitemsに1件あるのに画面は空。次に最も直接調べるものは？

  1. 根拠なしにDBのインデックスを追加する
  2. 200なので調査を終了する
  3. 応答の読み取り・画面の状態更新・描画をたどる
解答と解説

応答の読み取り・画面の状態更新・描画をたどる

期待したデータがブラウザーに届いているので、その後の画面処理を調べるのが直接的。200は表示の正しさを保証しない。この観測にはDBの検索性能が原因だと判断する根拠はない。