HTTPリクエストでどのような処理が行われているのか確認する

HTTPとはなんなのか？

HTTPとはHyper Text Transfer Protocolの略称で、ウェブブラウザとウェブサーバーの間でHTMLファイルや画像などのウェブ情報をやり取りするための通信ルール（プロトコル）です。

1回の通信で最低限起きていること

1. ブラウザがサーバに接続する
2. ブラウザがHTTPリクエストを送る
3. サーバがHTTPレスポンスを返す
4. ブラウザが受け取ったデータを使って画面を作る

HTTPは1つのリクエストには1つのレスポンスを返すルールになっていて、どちらかが多くなることはありません。
画像を読み込む、CSSを読み込むといった1つ1つの動作につき1回のやり取りが行われています。

HTTPSとは？

HTTPS(Hytertext Transfer Protocol Secure)は通信が暗号化されたHTTPです。
HTTPSはHTTPの別物というより、HTTPの会話をTLSという仕組みで暗号化して運ぶもの、というイメージです。
なので大元のシステムは同じで、それがシンプルに優れたものになったという認識で問題ありません。

基本的にHTTPがHTTPSより優れている部分はほとんどなく、早さも大して変わらないと言われています。
今では多くのサイトでHTTPSが使用されているのですが、もしクレジットカードや住所などの情報を入力するサイトがHTTPだったらやばいなと思いましょう。

ブラウザとサーバの通信をチェックする

さて、HTTPへの理解が深まってきたところで、実際にどのような動作をしているのか見てみましょう。

Chromeで開発者ツール(DevTools)を開いてネットワークのタブを押してみます。
そしてcmd+Rなどで画面を再読み込みすると、どのような通信が行われているのかが確認することができます。

なんか色々書いてますね。
内容はシンプルなので、1つ1つ見ていきましょう。

HTTPリクエストの詳細

全般

リクエストURL

ブラウザがサーバに対して「この場所のデータをください」と指定する宛先です。

URLにはだいたい次の情報が含まれます。

• 方式：http / https（どういう方法で通信するか）

• ホスト：prum.jp など（相手の名前）

• パス：/ や /news など（相手の中のどこか）

• クエリ：?q=...（追加条件、検索条件など）

リクエストメソッド

リクエストが「何をしたいか」を表す種類です。サーバへのお願いの動詞だと思うと分かりやすいです。

• GET：取ってきたい（取得）
• POST：送って処理してほしい（作成・実行）
• PUT/PATCH：更新したい
• DELETE：削除したい

メソッドを見ると、その通信が「表示のための取得」なのか「フォーム送信」なのかがすぐ分かります。

ステータスコードとは

サーバが返す「結果のサイン」です。数字だけで成功か失敗か、どの種類の失敗かを短く伝えます。
今回のステータスコードは200で、処理が正常に成功したという意味になります。

ステータスコードの種類

グループ	意味	何が起きたかの感覚
2xx	成功	うまくいった
3xx	リダイレクト	別の場所へ案内、またはキャッシュ利用
4xx	クライアント側の問題	お願いの仕方が悪い、権限がない
5xx	サーバ側の問題	サーバ内部で失敗した

よく見るステータスコード表

コード	名前	意味	よくある状況
200	OK	成功	期待した処理が完了した
201	Created	作成成功	登録や作成が完了した
204	No Content	成功だが返す中身なし	更新だけして画面に返すものがない
301	Moved Permanently	恒久的に移転	URLが変わったので今後はこっち
302	Found	一時的に移動	一時的に別URLへ
304	Not Modified	変更なし	新しいデータは返さないのでキャッシュを使え
400	Bad Request	リクエストが変	パラメータ不足、形式が違う
401	Unauthorized	認証が必要	ログインしてない、トークンがない
403	Forbidden	権限がない	ログインしてても許可されてない
404	Not Found	見つからない	URLが存在しない
429	Too Many Requests	送りすぎ	アクセスが多すぎて制限
500	Internal Server Error	サーバ内部エラー	サーバ側のコードが落ちた等
502	Bad Gateway	代理先が変	入口が奥のサーバと話せない
503	Service Unavailable	利用不可	混雑、メンテ、落ちてる

リモートアドレスとは

ブラウザが実際に接続した「相手のIPアドレスとポート番号」です。現実の接続先を示します。

例：118.27.122.21:443

• 118.27.122.21：IPアドレス（住所）
• 443：ポート（入口）

ポイントは、リクエストURLのドメイン名（例：prum.jp）は人間向けの名前で、最終的に通信するときはDNSによってIPに変換され、IPとポートで接続しに行く、ということです。

参照ポリシー（Referrer Policy）とは

ブラウザがリクエストを送るときに「どこから来たのか」を示す情報（Referer）を、どの範囲まで送るかを決めるルールです。

• Refererは「この通信は、元はこのページから発生した」という参照元情報
• 参照ポリシーは「その参照元情報をどこまで相手に見せるか」の設定

レスポンスヘッダー

レスポンスヘッダーはリクエストに対する返答です。（開発者ツールの順番的にこちらが上なので先に紹介しています）
HTTPがリクエストを送り、それに対するレスポンスをもらう仕組みという説明をしましたが、その部分です。

そして名前にヘッダーとついているように、ボディも一緒についてきています。
というかむしろボディが本体で、ヘッダーはその説明文という感じですね。

イメージとしては

• ヘッダー＝伝票（宛先、取り扱い注意、冷蔵、時間指定みたいな指示）
• ボディ＝箱の中身（実際の荷物）

という雰囲気で捉えてもらって大丈夫です。

レスポンスヘッダーがあると、どうなるのか？

ざっくりと言うと、ブラウザがボディ（中身）を正しく扱えるようになります。
レスポンスヘッダーはブラウザに対する「取り扱い説明書」です。

代表的に、ブラウザの動きが変わるものを挙げて説明します。

1) どんな中身なのか分かる（正しく表示できる）

• Content-Type: text/html → これはHTMLとして表示する
• Content-Type: application/json → これはデータ（JSON）として扱う
• Content-Type: image/png → これは画像として表示する

これがない/間違うと、表示が崩れたり、ダウンロード扱いになったりします。

2) キャッシュの効き方が決まる（更新が反映される/されないに直結）

• Cache-Control: max-age=3600 → 1時間は手元のコピー使ってOK
• Cache-Control: no-store → 保存するな（毎回取りに行け）

「直したのに反映されない」の原因がここにあることが多い。

3) Cookieが保存される（ログイン状態が維持される）

• Set-Cookie: session=... → ブラウザにこれを保存して、次回から送ってね

ログインができる/維持できるは、このヘッダーが関わります。

4) 別の場所へ移動させられる（リダイレクト）

• ステータスが301/302などのときに
  Location: https://... → 次はここへ行って

ブラウザはこの指示に従って自動で移動します。

リクエストヘッダー

リクエストヘッダーは、サーバに送る要求の中に入っている情報です。
HTTPはリクエストを送ってレスポンスを受け取る仕組みですが、リクエストヘッダーはその「送る側の条件・前提」を担います。

リクエストヘッダーがあると、どうなるのか？

ざっくり言うと、サーバが正しく判断できるようになります。
URLとメソッドだけでは足りない情報を、リクエストヘッダーで補っている感じです。
レストランに行って「食べ物をだしてください！」と言っても、お店の人は困ってしまいますよね？
それと同じで、「リブロースステーキをレアでお願いします」と注文しているのがここです。

代表的に、サーバ側の処理や返し方が変わるパターンを挙げます。

1) 何が欲しいかを伝えられる（返す形式が変わる）

• Accept: text/html → HTMLが欲しい
• Accept: application/json → JSONが欲しい

サーバはこれを見て、返すデータ形式を選びます。APIでHTMLが返ってきて困る、みたいな事故もここに関係します。

2) 言語や表示の好みを伝えられる（日本語優先など）

• Accept-Language: ja → 日本語優先
• Accept-Language: en-US → 英語優先

多言語サイトだと、どの言語のページを返すかの判断材料になります。

3) ログインしているか伝えられる（見える内容が変わる）

• Cookie: session=... → セッション情報を持ってる
• Authorization: Bearer ... → トークンを持ってる

これがあると会員向けの内容を返せるし、なければ401（認証が必要）になる、という世界です。

4) 送るデータの形式を伝えられる（サーバがボディを読める）

これは特にPOSTで重要です。

• Content-Type: application/json → ボディはJSONとして送る
• Content-Type: application/x-www-form-urlencoded → フォーム形式として送る

サーバはContent-Typeを見て、ボディをどう解釈するか決めます。ここがズレると、送ったのにサーバが受け取れないが起きやすいです。

5) キャッシュ確認ができる（無駄な通信を減らせる）

• If-None-Match: "abc" → 変わってなければ返さなくていい
• If-Modified-Since: ... → その日時以降に変わってなければ返さなくていい

サーバが変更なしと判断すると304を返して、ボディを送らずに済むことがあります。

まとめ

• HTTPとは、ブラウザとサーバがやり取りするためのルール
• HTTPはリクエストを送り、必ずそれに対するレスポンスが返る
• リクエストとレスポンスには、ヘッダーとボディがある
• 開発者ツール(DevTools)のNetworkで通信を見れば、何が起きているか追える