第6章｜今さら学ぶ「HTTP基礎」
📚 シリーズ目次はこちら → 「今さら学ぶ」シリーズ — はじめに
🗺️ KnowledgeNoteの設計を確認 → 設計マップ
この章でわかること
- GET / POST / PATCH / DELETE の役割と使い分け
- ステータスコードの意味 — 200, 302, 404, 500 は何を伝えているか
- CookieとSessionの仕組みと違い
- HTTPがわかると、Railsのルーティングやコントローラの理解が深まる理由
🏠 たとえ話で掴む「HTTP」
HTTP （HyperText Transfer Protocol）は、ブラウザとサーバが会話するための「共通語」です。
これを 図書館の窓口業務 にたとえて整理します。
図書館に行くと、窓口にはいくつかの業務があります。「本を借りたい」「新しい本を寄贈したい」「借りた本の情報を変えたい」「本を返却したい」。それぞれ対応する手続きが決まっています。
| 図書館の窓口 | HTTPメソッド | やること |
|---|---|---|
| 「この本を見せてください」 | GET | データを取得する（見るだけ） |
| 「新しい本を寄贈します」 | POST | 新しいデータを作成する |
| 「この本の情報を修正してください」 | PATCH | 既存データの一部を更新する |
| 「この本を除籍してください」 | DELETE | データを削除する |
図書館の窓口で「見せてください」と言ったのに勝手に本を処分されたら困ります。HTTPも同じで、 メソッドごとに「やっていいこと」が決まっています。
そして窓口の係員（サーバ）は、手続きが終わると結果を伝えます。「はい、この本です（200 OK）」「その本はありません（404 Not Found）」「内部でトラブルが起きました（500 Internal Server Error）」。これが ステータスコード です。
HTTPとは何か — 技術的な定義
プロトコルとしてのHTTP
HTTPは アプリケーション層のプロトコル（通信規約） です。ブラウザ（クライアント）がサーバにリクエストを送り、サーバがレスポンスを返す「リクエスト/レスポンス型」の通信モデルで設計されています。
Webの発明者ティム・バーナーズ＝リーが1991年に最初のバージョンを設計し、現在広く使われているのはHTTP/1.1とHTTP/2です。URLを入力してページが表示されるまでの通信は、すべてこのHTTPの仕組みで動いています。
HTTPの3つの重要な特徴
① ステートレス（状態を持たない）：サーバは1回のリクエスト/レスポンスが終わると、その通信の記憶を保持しません。2回目のリクエストは1回目と無関係に処理されます。この制約がCookieやSessionが必要になる理由です。
② テキストベース（HTTP/1.1まで）：リクエストもレスポンスもテキスト形式で構成されます。そのため、開発者ツールやcurlコマンドで中身を直接確認できます。
③ メソッドで操作の種類を指定する：GET（取得）、POST（作成）、PATCH（更新）、DELETE（削除）のように、リクエストに「何をしたいか」を明示します。これがRailsのRESTfulルーティングの土台になっています。
📬 HTTPメソッド — 4つの窓口業務
GET — 「見せてください」
GET は「データをください」というリクエストです。ブラウザでURLを入力したり、リンクをクリックしたりするとGETリクエストが送られます。
GET /articles/1 HTTP/1.1
Host: knowledgenote.example.com
GETの重要なルールは、 サーバのデータを変更しない こと。何回アクセスしても同じ結果が返ってくるべきです（これを 冪等性（べきとうせい） と言います）。
# routes.rb — GETリクエストの定義
resources :articles, only: [:index, :show]
# GET /articles → articles#index（記事一覧を見る）
# GET /articles/1 → articles#show（記事1件を見る）
POST — 「新しく作ってください」
POST は「新しいデータを作ってください」というリクエストです。フォームの送信ボタンを押したときなどに使われます。
POST /articles HTTP/1.1
Host: knowledgenote.example.com
Content-Type: application/x-www-form-urlencoded
article[title]=Ruby入門&article[body]=Rubyとは...
POSTは リクエストのボディ（本体）にデータを含めて送信 します。GETとの大きな違いは、URLにデータが表示されないことです。
# routes.rb — POSTリクエストの定義
resources :articles, only: [:create]
# POST /articles → articles#create（記事を新規作成する）
PATCH — 「一部を修正してください」
PATCH は「既存データの一部を更新してください」というリクエストです。
PATCH /articles/1 HTTP/1.1
Host: knowledgenote.example.com
article[title]=Ruby入門（改訂版）
💡 PUT と PATCH の違い： PUTは「全体を置き換える」、PATCHは「一部を修正する」という意味です。Railsでは
PATCHが標準で使われます。
DELETE — 「削除してください」
DELETE は「このデータを削除してください」というリクエストです。
DELETE /articles/1 HTTP/1.1
Host: knowledgenote.example.com
KnowledgeNoteでの4メソッドの対応
| HTTPメソッド | URL | Railsのアクション | やること |
|---|---|---|---|
| GET | /articles |
articles#index |
記事一覧を表示 |
| GET | /articles/1 |
articles#show |
記事1件を表示 |
| GET | /articles/new |
articles#new |
作成フォームを表示 |
| POST | /articles |
articles#create |
記事を作成 |
| GET | /articles/1/edit |
articles#edit |
編集フォームを表示 |
| PATCH | /articles/1 |
articles#update |
記事を更新 |
| DELETE | /articles/1 |
articles#destroy |
記事を削除 |
この7つのパターンが、Railsの resources で自動生成されるルートの全体像です（→ 第10章で詳しく扱います）。
📊 ステータスコード — サーバからの返事
HTTPリクエストを受け取ったサーバは、必ず ステータスコード という3桁の数字を返します。これは窓口の係員からの返事です。
覚えておくべきコード
| コード | 意味 | 図書館のたとえ | Railsでの場面 |
|---|---|---|---|
| 200 OK | 成功 | 「はい、この本です」 | ページの正常表示 |
| 201 Created | 作成成功 | 「寄贈ありがとうございます。登録しました」 | API で新規作成成功時 |
| 302 Found | リダイレクト | 「その本は3階に移動しました。そちらへどうぞ」 | redirect_to |
| 400 Bad Request | リクエストが不正 | 「申請書の書き方が間違っています」 | パラメータ不正 |
| 401 Unauthorized | 認証が必要 | 「利用者カードを見せてください」 | 未ログイン |
| 403 Forbidden | アクセス禁止 | 「この本は閲覧制限があります」 | 権限不足 |
| 404 Not Found | 見つからない | 「その本は当館にはありません」 | 存在しないURL |
| 422 Unprocessable Content | 処理不能 | 「申請内容に不備があります」 | バリデーションエラー |
| 500 Internal Server Error | サーバエラー | 「すみません、こちらのシステムに障害が…」 | アプリのバグ |
ステータスコードの法則
百の位で大まかな意味がわかります。
| 百の位 | 意味 | ひとこと |
|---|---|---|
| 1xx | 情報 | 「処理中です」（あまり見かけない） |
| 2xx | 成功 | 「うまくいきました」 |
| 3xx | リダイレクト | 「別の場所に移動してください」 |
| 4xx | クライアントエラー | 「あなた（ブラウザ）側の問題です」 |
| 5xx | サーバエラー | 「こちら（サーバ）側の問題です」 |
Railsでのステータスコード指定
Railsでは、ステータスコードをシンボルで指定できます。
# コントローラでの使用例
def create
@article = current_user.articles.build(article_params)
if @article.save
redirect_to @article, notice: "記事を投稿しました"
# ↑ 302リダイレクトが自動で返される
else
render :new, status: :unprocessable_entity
# ↑ 422を返す（バリデーションエラー）
# ※ シンボル名は旧称（Unprocessable Entity）由来。正式名は RFC 9110 で Unprocessable Content に改称済み
end
end
# よく使うシンボル一覧
status: :ok # 200
status: :created # 201
status: :no_content # 204
status: :found # 302（redirect_toのデフォルト）
status: :not_found # 404
status: :unprocessable_entity # 422
status: :internal_server_error # 500
🍪 CookieとSession — 名札と受付名簿
HTTPには大きな特徴があります。それは ステートレス（状態を持たない） ということです。
サーバは1回のリクエストが終わると、「さっきのリクエストを誰が送ったか」を忘れてしまいます。図書館のたとえでいうと、窓口の係員が10秒ごとに記憶喪失になるようなものです。
しかし実際のWebアプリでは「ログイン状態を維持する」「カートの中身を覚える」など、ユーザーの状態を保持する必要があります。そこで使われるのが Cookie と Session です。
Cookie — 利用者が持つ「名札」
Cookie（クッキー） は、サーバがブラウザに渡す小さなデータです。利用者が首から下げる名札のようなものです。
【仕組み】
1. 初回アクセス → サーバが「名札」を渡す（Set-Cookie ヘッダー）
2. 2回目以降 → ブラウザが毎回「名札」を見せる（Cookie ヘッダー）
3. サーバは名札を見て「ああ、さっきの人ね」と認識する
# サーバからブラウザへ（レスポンス）
Set-Cookie: user_name=tanaka; Path=/; HttpOnly
# ブラウザからサーバへ（次回のリクエスト）
Cookie: user_name=tanaka
Cookieの特徴は、 ブラウザ（利用者側）に保存される ことです。そのため、利用者が中身を見たり改ざんしたりできます。パスワードなどの秘密情報を直接入れてはいけません。WebのセキュリティリスクとCSRFについては（→ 第20章で詳しく扱います）。
Session — サーバ側の「受付名簿」
Session（セッション） は、サーバ側にデータを保存する仕組みです。図書館の受付カウンターの裏にある名簿のようなものです。
【仕組み】
1. ログイン成功 → サーバが受付名簿に記録し、「整理番号」だけをCookieで渡す
2. 2回目以降 → ブラウザは「整理番号」だけ見せる
3. サーバは整理番号で名簿を引き、「この人はログイン済みの田中さんだ」と認識する
Cookieとの違いは、 実際のデータはサーバ側に保管されている こと。ブラウザに渡すのは「セッションID」という整理番号だけです。
CookieとSessionの使い分け
| Cookie（名札） | Session（受付名簿） | |
|---|---|---|
| データの保存場所 | ブラウザ（利用者側） | サーバ側 |
| 改ざんリスク | あり（利用者が変更可能） | 低い（サーバで管理） |
| データ量の制限 | 4KB程度 | サーバの容量次第 |
| 使いどころ | 言語設定、テーマの好み | ログイン状態、ユーザーID |
# Railsでのセッション操作
class SessionsController < ApplicationController
def create
user = User.find_by(email_address: params[:email_address])
if user&.authenticate(params[:password])
session[:user_id] = user.id # セッションにユーザーIDを保存
redirect_to root_path, notice: "ログインしました"
else
flash.now[:alert] = "メールアドレスまたはパスワードが間違っています"
render :new, status: :unprocessable_entity
end
end
def destroy
session.delete(:user_id) # セッションからユーザーIDを削除
redirect_to root_path, notice: "ログアウトしました"
end
end
💡 Rails 8 のセッション管理
Rails 8 の組み込み認証では、セッション情報をsessionsテーブルでDB管理します。これにより「どの端末からログインしているか」を一覧でき、個別のセッションを無効化（ログアウト）することもできます（→ 第21章で詳しく扱います）。
🔄 リクエストとレスポンスの全体像
第0章で学んだ「宅配ピザ」の流れを、HTTP用語で改めて整理します。
ブラウザ サーバ
┌──────────┐ ┌──────────────┐
│ │ ── リクエスト ──> │ │
│ │ GET /articles/1 │ ルーティング │
│ │ Cookie: session= │ ↓ │
│ │ abc123 │ コントローラ │
│ │ │ ↕（C↔M） │
│ │ │ モデル＋DB │
│ │ │ ↓（C経由） │
│ │ <── レスポンス ── │ ビュー │
│ │ HTTP/1.1 200 OK │ │
│ │ Content-Type: │ │
│ │ text/html │ │
│ │ │ │
│ │ <html>...</html> │ │
└──────────┘ └──────────────┘
リクエストの中身
GET /articles/1 HTTP/1.1 ← リクエストライン（メソッド + URL + HTTPバージョン）
Host: knowledgenote.example.com ← ヘッダー（宛先）
Accept: text/html ← ヘッダー（どの形式で返してほしいか）
Cookie: _session_id=abc123 ← ヘッダー（セッション情報）
レスポンスの中身
HTTP/1.1 200 OK ← ステータスライン（結果）
Content-Type: text/html ← ヘッダー（返すデータの種類）
Set-Cookie: _session_id=abc123 ← ヘッダー（Cookieを設定）
<html> ← ボディ（実際のデータ）
<body>
<h1>Ruby入門</h1>
...
</body>
</html>
🛠️ KnowledgeNoteでの具体例
KnowledgeNoteの「いいねボタン」を押したときのHTTP通信を追ってみます。
1. ユーザーが「❤️ いいね」ボタンを押す
2. ブラウザがリクエストを送る
POST /likes HTTP/1.1
Cookie: _session_id=abc123
article_id=1
3. サーバ（Rails）が処理する
- ルーティング → LikesController#create
- セッションから current_user を特定
- Like.create!(user: current_user, likeable: article)
4. サーバがレスポンスを返す
HTTP/1.1 200 OK
Content-Type: text/vnd.turbo-stream.html
（Turbo Streamsでいいねボタンを更新するHTMLの断片）
5. ブラウザが画面を部分更新（ページ全体の再読み込みなし）
HTTPの基礎がわかっていると、Turbo Streams（→ 第19章）のような仕組みも「HTTPリクエスト/レスポンスの応用」として理解できます。
💼 面接で聞かれたら？
Q：GETとPOSTの違いを説明してください。
「GETはサーバからデータを取得するリクエストで、データを変更しません。パラメータはURLに含まれます。POSTは新しいデータを作成するリクエストで、データはリクエストボディに含めて送信します。GETは何度実行しても同じ結果を返すべきですが、POSTは実行のたびに新しいデータが作られるので、結果が変わります。」
深掘りされたら：
- 「ステータスコード404と500の違いは？」→ 404はクライアント側の問題で、リクエストしたリソースが存在しない状態。500はサーバ側の問題で、アプリのバグや障害が原因。404は正常な動作（存在しないURLへのアクセス）だが、500は異常事態。
- 「CookieとSessionの違いは？」→ Cookieはブラウザ側にデータを保存する仕組み。Sessionはサーバ側にデータを保存し、ブラウザにはセッションIDだけを渡す。秘密情報はSessionで管理する。
🔗 もっと深く知りたい人へ（1次情報リンク）
- MDN Web Docs：HTTP の概要 — HTTPの全体像を基礎から解説
- MDN Web Docs：HTTP レスポンスステータスコード — 全ステータスコードの一覧と解説
- MDN Web Docs：Cookie — Cookieの仕組みとセキュリティ
- Rails ガイド：Action Controller の概要 — セッション・Cookie・フラッシュの扱い方
まとめ
- ✅ HTTPはブラウザとサーバの「共通語」。GET（見る）/ POST（作る）/ PATCH（直す）/ DELETE（消す）の4メソッドが基本
- ✅ ステータスコードはサーバからの返事。2xx=成功、3xx=リダイレクト、4xx=クライアントエラー、5xx=サーバエラー
- ✅ HTTPはステートレス（状態を持たない）。状態の保持にはCookieとSessionを使う
- ✅ Cookieはブラウザ側に保存（名札）、Sessionはサーバ側に保存（受付名簿）
- ✅ HTTPの基礎がわかると、Railsのルーティング・コントローラ・Turbo Streamsの理解が深まる
📚 シリーズ目次：「今さら学ぶ」シリーズ — はじめに