Web と HTTP

Web アプリを作るということは、HTTP でやり取りするものを作るということです。

フロントエンドもバックエンドも、間にあるのは HTTP です。 「API が動かない」「なぜか 401 が返る」「CORS エラーが出た」—— 新人が最初にぶつかる問題のほとんどは、HTTP を知らないと解けません。

この章では、ブラウザの開発者ツールを開いて中身を読めるところまでを目指します。

URL は住所ではなく命令書

まず URL を分解します。何気なく見ているこの文字列には、意味のある部品が詰まっています。

https://api.example.com:443/items/42?sort=price&limit=20#reviews
└─┬─┘  └──────┬───────┘└┬┘└──┬───┘└────────┬─────────┘└──┬──┘
scheme      host       port  path         query        fragment

リクエストとレスポンス

HTTP は、テキストのやり取りです。ブラウザが送っているのは、実際にはこういう文字列です。

GET /items/42?sort=price HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGciOi...
User-Agent: Mozilla/5.0 ...
 

サーバーが返すのはこれです。

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: no-store
Content-Length: 87
 
{"id":42,"name":"ワイヤレスイヤホン","price":8900}

構造は3つです。

1. 1行目 — リクエストなら「メソッド + パス」、レスポンスなら「ステータスコード」
2. ヘッダ — 名前: 値 の並び。付帯情報
3. 空行のあとにボディ — 実際のデータ

これがすべてです。 GraphQL も gRPC も REST も、この上に載っているだけです。

メソッド

冪等（べきとう） とは「何度実行しても結果が同じ」という性質です。

なぜこれが重要かというと、通信は失敗するからです。 レスポンスが返ってこなかった時、リトライしていいかどうかは冪等かどうかで決まります。

ステータスコード

全部覚える必要はありません。先頭の数字が意味を持ちます。

4xx と 5xx の境界が最も重要です。障害対応で最初に見るのがここで、 「4xx が増えた」ならクライアントの使い方かバリデーション、 「5xx が増えた」ならサーバーが壊れている、と切り分けられます。

覚えておくべきものだけ挙げます。

ヘッダ

よく見るものだけ挙げます。

状態を持たない HTTP で、なぜログインが維持されるのか

HTTP はステートレスです。1回のリクエストが終わったら、サーバーはあなたを忘れます。

ではなぜ、ページを移動してもログインしたままなのでしょうか。 毎回「自分が誰か」を証明する情報を送っているからです。

Cookie とセッション

1. ログイン          POST /login  { email, password }
2. サーバーが発行     Set-Cookie: session_id=abc123; HttpOnly; Secure
3. ブラウザが保存
4. 以降のリクエスト   Cookie: session_id=abc123      ← 自動で付く
5. サーバーが照合     abc123 → ユーザーID 42 だな

サーバー側は「セッション ID → ユーザー」の対応表を持っています。 ログアウトはこの対応表から消すだけで、確実に無効化できます。

トークン（JWT）

セッションの代わりに、署名付きのトークンを渡す方式もあります。

Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjo0Mn0.xxxxx

サーバーは対応表を持たず、署名を検証するだけでユーザーを特定できます。 サーバーを増やしやすいので、マイクロサービスでよく使われます。

キャッシュ

同じものを何度も取りに行かないための仕組みです。

CORS — 実務で最も時間が溶けるエラー

独立した節にする価値があります。それくらい遭遇します。

何が起きているか

ブラウザには同一オリジンポリシーというルールがあります。 https://app.example.com で開いているページから https://api.example.com へリクエストすると、ブラウザが結果を渡してくれません。

オリジンとは スキーム + ホスト + ポート の3点セットです。1つでも違えば別オリジンです。

https://app.example.com        （基準）
https://api.example.com   → ホストが違う   別オリジン
http://app.example.com    → スキームが違う 別オリジン
https://app.example.com:8080 → ポートが違う 別オリジン

なぜそんな制限があるのか

もし制限がなければ、悪意あるサイトを開いただけで、 そのサイトの JavaScript があなたのログイン中の銀行サイトに勝手にリクエストを送り、 結果を読み取れてしまいます。それを防ぐための仕組みです。

どう解決するか

サーバー側が「このオリジンからは許可する」と応答ヘッダで宣言します。

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true

プリフライト

単純ではないリクエストの場合、ブラウザは本番のリクエストの前に OPTIONS を送って 許可を確認します。これがプリフライトです。

プリフライトが飛ぶ条件（代表的なもの）:

• GET HEAD POST 以外のメソッド（PUT DELETE PATCH）
• Content-Type: application/json を使う
• Authorization などのカスタムヘッダを付ける

つまり普通の JSON API はほぼ全部プリフライトが飛びます。

開発者ツールの Network タブで、同じ URL に対して OPTIONS と POST の 2行が出ていれば、それがプリフライトです。

開発者ツールの Network タブ

実務で毎日使います。読み方を覚えてください。

Cmd+Option+I（Mac）で開き、Network タブを選んで、ページを再読み込みします。

REST の考え方

「リソース」を URL で表し、「操作」をメソッドで表す設計スタイルです。

悪い例（操作を URL に書いている）
  POST /getItem?id=42
  POST /updateItemName
  POST /deleteItem

良い例（リソース + メソッド）
  GET    /items/42
  PATCH  /items/42
  DELETE /items/42

• URL は名詞（リソース）、メソッドが動詞（操作）
• 複数形を使う（/items）
• 階層で関係を表す（/items/42/reviews）

実務の落とし穴まとめ

1. CORS はサーバー側で直す — フロントをいくら直しても解決しない
2. OPTIONS を認証対象にしない — プリフライトが 401 で落ちる
3. Content-Type の付け忘れ — JSON なのに 400 が返る
4. GET で状態を変える — クローラに勝手に実行される
5. クエリに秘密情報 — ログ・履歴・Referer に残る
6. キャッシュを疑わない — 「直したのに反映されない」の主犯
7. 401 と 403 を混同 — 認証と認可は別のもの

まとめ

• HTTP は「1行目 + ヘッダ + 空行 + ボディ」のテキスト。これがすべて
• 4xx はクライアント、5xx はサーバー。障害対応の切り分けはここから
• 401 = 誰か分からない、403 = 権限がない
• ステートレスな HTTP でログインが続くのは、毎回証明を送っているから
• Cookie は HttpOnly Secure SameSite を付ける。JWT の中身は誰でも読める
• CORS はサーバー側の設定。プリフライト（OPTIONS）に認証を要求しない
• 困ったら開発者ツールの Network タブ。ステータス・リクエストヘッダ・ボディを見る

章末問題

次の章では、このリクエストを実際に投げているブラウザの中で 何が起きているのかを見ていきます。