2-2. Webの仕組み

このセクションで学ぶこと

ブラウザとサーバーが HTTP で会話する流れ
HTTP メソッド、ヘッダー、ステータスコードの意味
REST の基本的な考え方
Cookie と認証の役割

1. ブラウザとサーバーは何をやり取りしているのか

Web ブラウザでページを開くとき、裏では HTTP（Hypertext Transfer Protocol） というルールで通信している。
普段よく見る https:// は、HTTP を TLS で保護した通信 である。ここではまず「HTTP を安全に包んだもの」と理解できれば十分である。

ブラウザ                     サーバー
   │  HTTPリクエスト             │
   ├──────────────────────────▶│
   │                           │
   │  HTTPレスポンス             │
   ◀──────────────────────────┤

URL の見方

たとえば次の URL を考える。

https://api.example.com/books/42?lang=ja

部分	例	意味
スキーム	`https`	どの通信ルールで接続するか
ホスト	`api.example.com`	どのサーバーに接続するか
パス	`/books/42`	どの資源を取りに行くか
クエリ文字列	`lang=ja`	追加条件

リクエストとレスポンスの例

GET /books/42 HTTP/1.1
Host: api.example.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{"id":42,"title":"Network Basics"}

この例から分かるように、HTTP 通信には主に次の要素がある。

メソッド：何をしたいか（GET, POST など）
ヘッダー：追加情報（欲しい形式、Cookie など）
ボディ：本文（JSON や HTML など）
ステータスコード：結果がどうなったか

2. HTTP メソッドとステータスコード

HTTP では、同じ URL でもメソッドによって意味が変わる。

よく使うメソッド

メソッド	主な用途	イメージ
`GET`	データ取得	読む
`POST`	新規作成	作る
`PUT`	全体更新	全部入れ替える
`PATCH`	部分更新	一部だけ変える
`DELETE`	削除	消す

なぜメソッドを分けるのか

もし「読む」「作る」「消す」を全部同じ扱いにすると、リクエストの意図が分かりにくくなる。
そのため HTTP では、操作の意味をメソッドに持たせる。

たとえば GET /books/42 は「42番の本を取得したい」、DELETE /books/42 は「42番の本を削除したい」と読める。

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

コード	意味	典型例
`200`	成功	取得や更新が成功した
`201`	作成成功	新しい資源を作れた
`301` / `302`	リダイレクト	別の場所へ移動している
`400`	リクエスト不正	送り方が間違っている
`401`	未認証	ログインや認証情報が必要
`403`	禁止	認証済みでも権限がない
`404`	見つからない	URL が存在しない
`500`	サーバーエラー	サーバー側で問題が起きた

401 と 403 の違い

初心者がよく混同するのが 401 と 403 である。

401：まず「あなたが誰か」を示してほしい
403：誰かは分かったが、その操作は許可できない

つまり、401 は認証不足、403 は権限不足と考えると整理しやすい。

3. REST とは何か

REST は、Web API を設計するときの代表的な考え方である。
細かい制約は多いが、研修ではまず次の2点を押さえればよい。

URL は 資源（リソース） を表す
操作の種類は HTTP メソッド で表す

REST 的な URL の例

操作	例	意味
本一覧を取得	`GET /books`	本の集合を読む
本を1冊取得	`GET /books/42`	42番の本を読む
本を追加	`POST /books`	本を新規作成する
本を更新	`PATCH /books/42`	42番の本の一部を更新する
本を削除	`DELETE /books/42`	42番の本を削除する

なぜこの形が分かりやすいのか

URL に「何の資源か」を、メソッドに「何をしたいか」を分けることで、API の意味が読み取りやすくなる。

/books/42
   ↑
   どの資源か

GET / POST / PATCH / DELETE
   ↑
   何をしたいか

もし URL の中に操作名を大量に埋め込むと、設計ルールがばらばらになりやすい。
REST は、読みやすく、そろえやすい API を作るための考え方でもある。

HTTP は基本的に stateless（ステートレス） なプロトコルである。
つまり、1回1回のリクエストは独立しており、サーバーは前回の会話を自動では覚えていない。

ステートレスだと何が困るのか

たとえばログインのあるサイトで、毎回「この人は誰か」が分からなければ、ページを移動するたびに再ログインが必要になってしまう。

そこで使われるのが Cookie である。

1. ブラウザがログインする
2. サーバーが Set-Cookie で識別子を返す
3. ブラウザがその値を保存する
4. 次回以降のリクエストで Cookie を自動送信する

HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; HttpOnly; Secure

GET /books HTTP/1.1
Host: app.example.com
Cookie: session_id=abc123

Cookie 自体に大量の情報を入れるとは限らない。
実際には、サーバー側の状態を引くための識別子 を入れることが多い。

つまり Cookie は「ログインそのもの」ではなく、ログイン済みの状態を継続するための鍵 に近い。

5. 認証とは何か

認証（Authentication） とは、「あなたは誰か」を確認すること。
一方、認可（Authorization） とは、「その人にその操作を許すか」を決めること。

用語	意味	例
認証	本人確認	ログインしているか
認可	権限確認	管理者画面へ入れるか

典型的な認証の流れ

ブラウザ
   │  ID / パスワード送信
   ▼
サーバー
   │  確認する
   ▼
認証成功
   │  セッションIDやトークンを返す
   ▼
以後のリクエストで継続利用

セッションCookie とトークン

方式	概要
セッションCookie	ブラウザが Cookie で識別子を送り、サーバー側でログイン状態を管理する
トークン	クライアントが `Authorization` ヘッダーなどでトークンを送る

研修のこの段階では、どちらも「認証済みであることを次のリクエストへ持ち越す仕組み」と理解できれば十分である。
パスワードハッシュや HTTPS、脆弱性の話は第6章で詳しく扱う。

6. `curl` で HTTP を観察する

HTTP はブラウザの中で自動的に使われるため、見えにくい。
そこで、コマンドラインから HTTP を送れる curl を使うと観察しやすい。

ヘッダーだけ見る

curl -I https://example.com

-I はレスポンスヘッダーだけを表示する
ステータスコードや content-type などを確認しやすい

JSON を見る

curl https://api.github.com/repos/octocat/Hello-World

サーバーから返る JSON をそのまま観察できる
Web API が「URL に対してデータ表現を返す」ことを実感しやすい

ここで大切なのは、コマンドを暗記することではなく、HTTP は画面の裏で実際にリクエストとレスポンスをやり取りしている と見えるようになることである。

まとめ

キーワード	説明
HTTP	ブラウザとサーバーがやり取りするためのルール
メソッド	何をしたいかを表す（GET, POST など）
ステータスコード	リクエスト結果を表す番号
REST	URL は資源、メソッドは操作として考える設計
Cookie	ブラウザが保持し、次回リクエストで送る小さなデータ
ステートレス	前回の会話を自動では覚えない性質
認証	本人確認
認可	権限確認
`curl`	HTTP 通信を観察できるコマンドラインツール

次のステップ

演習問題に取り組んで理解を確認しよう。

第2章を終えたら、3-1. Gitの基礎へ進もう。