HTTPリクエストの読み方

今回やること

この記事では、HTTPリクエストを上から順に読みます。

HTTPリクエストは「何をしたいか」「どこに送るか」「どんな形式で送るか」「誰として送るか」を見ると理解しやすくなります。

HTTPの仕組み自体は別記事で扱っているため、ここではDevToolsやcurlの表示を読めるようになることに絞ります。

リクエスト全体の形

HTTPリクエストは、主に3つの部分でできています。

POST /api/contact HTTP/1.1
Host: example.com
Accept: application/json
Content-Type: application/json
Authorization: Bearer xxxxxx

{"name":"Ada","message":"hello"}

最初から全部を暗記する必要はありません。まずは、メソッド、URL、Content-Type、認証情報、ボディの有無を見ます。

Step 1: メソッドを見る

リクエストの先頭にある GET や POST がメソッドです。

GET /articles?page=2 HTTP/1.1

代表的な読み方は次の通りです。

たとえば、ログインフォームで GET が使われていたら注意が必要です。メールアドレスやパスワードがURLに出る可能性があります。ログインや問い合わせ送信のように本文を送る処理は、通常 POST で扱います。

Step 2: パスとクエリを見る

メソッドの次にある /articles?page=2 の部分は、サーバー内のどの場所を呼んでいるかを表します。

GET /search?q=javascript&page=1 HTTP/1.1

この例では、パスは /search、クエリは q=javascript&page=1 です。

検索、絞り込み、並び替え、ページ番号のような条件はクエリに入ることが多いです。一方で、パスそのものが間違っていると 404 Not Found になりやすいです。

DevToolsでは、Networkパネルの Headers にある Request URL を確認します。URLが想定と違う場合、フロント側のリンク、フォームの action、APIのベースURL設定を見直します。

Step 3: Hostを見る

Host ヘッダーは、どのドメイン宛てのリクエストかを示します。

Host: api.example.com

同じサーバーIPに複数のサイトが置かれていることがあるため、サーバーは Host を見て処理対象を判断します。

開発中にAPIがつながらない場合、次のようなミスがあります。

Request URL と Host が想定通りかを見るだけで、かなりの設定ミスを発見できます。

Step 4: Acceptを見る

Accept は、クライアントが受け取りたい形式をサーバーに伝えるヘッダーです。

Accept: application/json

よく見る値は次の通りです。

APIを呼んでいるのにHTMLのエラーページが返る場合、URLがAPIではなく画面用ルートを向いていることがあります。Accept だけで決まるわけではありませんが、クライアント側が何を期待しているかを見る手がかりになります。

Step 5: Content-Typeを見る

Content-Type は、リクエストボディの形式を表します。

Content-Type: application/json

サーバーはこの値を見て、本文をJSONとして読むのか、フォームとして読むのか、ファイルアップロードとして読むのかを判断します。

POST しているのにサーバーが値を受け取れない場合、まず Content-Type と実際のボディ形式が一致しているかを見ます。JSONを送っているのに Content-Type がない、またはフォーム形式として送っていると、サーバー側で空として扱われることがあります。

Step 6: CookieとAuthorizationを見る

ログインが関係するリクエストでは、認証情報を確認します。

Cookie: session_id=abc123
Authorization: Bearer xxxxxx

ログイン済みのはずなのに 401 Unauthorized になる場合、Cookieが送られていない、トークンが期限切れ、送信先ドメインが違う、CORS設定で認証情報が落ちている、などが考えられます。

本番の調査では、CookieやAuthorizationの値をそのまま共有しないようにします。スクリーンショットやログを出す前に、値を伏せます。

Step 7: ボディを見る

POST、PUT、PATCH では、ヘッダーの下に本文が付くことがあります。

POST /api/users HTTP/1.1
Content-Type: application/json

{"name":"Ada","email":"ada@example.com"}

確認するポイントは次の通りです。

• 必要な項目が入っているか
• キー名がサーバー側の期待と一致しているか
• 数値や真偽値が文字列になっていないか
• 空文字や null を送っていないか
• Content-Type と本文の形式が一致しているか

APIエラーでは、ステータスコードだけでなく、送ったボディの中身を見ることが重要です。サーバーが正しくても、フロント側が間違ったキー名で送っていればバリデーションエラーになります。

読み方の練習

次のリクエストを読んでみます。

POST /api/login HTTP/1.1
Host: app.example.com
Accept: application/json
Content-Type: application/json

{"email":"student@example.com","password":"secret"}

読み取り:

このリクエストで失敗した場合は、まずURL、メソッド、JSONのキー名、Content-Type、レスポンスのステータスコードを確認します。

もう1つ見ます。

GET /dashboard HTTP/1.1
Host: app.example.com
Cookie: session_id=abc123
Accept: text/html

読み取り:

この場合、Cookieが送られているのにログイン画面へ戻されるなら、セッション期限切れ、Cookieのドメイン設定、サーバー側のセッション削除などを疑います。

DevToolsで見る場所

Chrome DevToolsでは、Networkパネルで対象リクエストを選びます。

Networkを開く前に通信が終わっていると見えないことがあります。Networkパネルを開いてからページを再読み込みします。

まとめ

HTTPリクエストは、メソッド、パス、クエリ、Host、Accept、Content-Type、認証情報、ボディの順に見ると整理できます。

特にAPIやフォーム送信で詰まったときは、画面のエラーメッセージだけで判断せず、実際にどんなリクエストが送られているかをDevToolsで確認します。

参考リソース

• MDN: HTTP messages
• MDN: HTTP request methods
• Chrome DevTools: Network panel

×

PR

×

PR