| この記事の要点 |
- HTTP (Hyper Text Transfer Protocol) は Web の基本プロトコル。TCP/80、HTTPS は TCP/443
- メソッドは GET / POST / PUT / DELETE / PATCH / HEAD / OPTIONS。冪等性 (idempotent) が REST 設計の鍵
- ステータスコードは 1xx 情報 / 2xx 成功 / 3xx リダイレクト / 4xx クライアントエラー / 5xx サーバエラー
- ヘッダで
Content-Type / Authorization / Cookie / Cache-Control / CORS 等を交渉 - HTTP/1.1 (テキスト) → HTTP/2 (バイナリ・多重化) → HTTP/3 (QUIC/UDP) と進化中
|
HTTP の基本
HTTP (Hyper Text Transfer Protocol) は、Web ブラウザと Web サーバの間でリソース (HTML / 画像 / JSON 等) をやりとりするためのプロトコル。リクエスト / レスポンス型のステートレスプロトコルで、1990 年に Tim Berners-Lee が考案、現在は HTTP/1.1 (RFC 9112) / HTTP/2 (RFC 9113) / HTTP/3 (RFC 9114) が標準。
| 項目 | HTTP | HTTPS |
|---|
| ポート | 80/tcp | 443/tcp (HTTP/3 は 443/udp) |
| 暗号化 | 無し | TLS |
| URL スキーム | http:// | https:// |
リクエスト / レスポンスのフォーマット
# リクエスト
GET /api/users/1 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (...)
Accept: application/json
Authorization: Bearer eyJhbGc...
# レスポンス
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 47
Cache-Control: max-age=60
Date: Wed, 11 Jun 2026 00:00:00 GMT
{"id":1,"name":"Alice","email":"a@example.com"}
HTTP メソッド
| メソッド | 用途 | Safe | Idempotent | ボディ |
|---|
| GET | リソース取得 | ○ | ○ | × |
| HEAD | ヘッダのみ取得 | ○ | ○ | × |
| POST | 新規作成・任意処理 | × | × | ○ |
| PUT | 全置換 / 作成 | × | ○ | ○ |
| PATCH | 部分更新 | × | × | ○ |
| DELETE | 削除 | × | ○ | ×/○ |
| OPTIONS | 許可メソッド確認 (CORS preflight) | ○ | ○ | × |
| CONNECT | HTTPS プロキシトンネル | × | × | × |
| TRACE | 診断用 (通常無効化推奨) | ○ | ○ | × |
Safe: 副作用がない / Idempotent: 何度実行しても結果が同じ。REST API 設計の核となる概念です。
ステータスコード
| 分類 | 意味 | 代表例 |
|---|
| 1xx | 情報 | 100 Continue / 101 Switching Protocols (WebSocket) |
| 2xx | 成功 | 200 OK / 201 Created / 204 No Content |
| 3xx | リダイレクト | 301 Moved Permanently / 302 Found / 304 Not Modified / 307 / 308 |
| 4xx | クライアントエラー | 400 Bad Request / 401 Unauthorized / 403 Forbidden / 404 Not Found / 409 Conflict / 422 Unprocessable / 429 Too Many Requests |
| 5xx | サーバエラー | 500 Internal Server Error / 502 Bad Gateway / 503 Service Unavailable / 504 Gateway Timeout |
代表的なヘッダ
| カテゴリ | ヘッダ | 用途 |
|---|
| コンテンツ | Content-Type | ボディの MIME (例: application/json) |
Content-Length | ボディサイズ (byte) |
Content-Encoding | 圧縮形式 (gzip / br / zstd) |
| 認証 | Authorization | Bearer xxx / Basic xxx |
WWW-Authenticate | 401 時にクライアントへ要求方式を提示 |
| セッション | Cookie | クライアント→サーバへ Cookie 送信 |
Set-Cookie | サーバ→クライアントへ Cookie 発行 |
| キャッシュ | Cache-Control | no-store / max-age=60 / public |
ETag | リソース版識別子（条件付き GET） |
Last-Modified | 最終更新日時 |
| CORS | Origin | リクエスト元オリジン |
Access-Control-Allow-Origin | サーバが許可するオリジン |
Access-Control-Allow-Methods | 許可メソッド |
HTTP/1.1 vs HTTP/2 vs HTTP/3
| 項目 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|
| RFC | 9112 (旧 2616) | 9113 (旧 7540) | 9114 |
| 形式 | テキスト | バイナリフレーム | バイナリフレーム |
| 多重化 | 不可（1 接続 1 リクエスト） | 1 TCP 接続で多重ストリーム | QUIC ストリーム多重化 |
| ヘッダ圧縮 | 無し | HPACK | QPACK |
| サーバプッシュ | 無し | あり (近年は非推奨) | あり |
| 下層 | TCP | TCP + TLS | ★ UDP + QUIC + TLS 1.3 |
| ハンドシェイク | TCP 3way + TLS | 同上 | 1-RTT (0-RTT も可) |
| HOL ブロッキング | あり (パイプライン不完全) | あり (TCP 層) | ★ 無し (ストリーム独立) |
curl での操作例
# GET
curl -i https://example.com/
# POST JSON
curl -X POST https://example.com/api/users \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer XYZ' \
-d '{"name":"Alice"}'
# ヘッダのみ
curl -I https://example.com/
# HTTP/2 / HTTP/3 を強制
curl --http2 https://example.com/
curl --http3 https://example.com/
# 詳細ログ
curl -v https://example.com/
# Cookie 保存・送信
curl -c jar.txt -b jar.txt https://example.com/
# ファイルアップロード
curl -F 'file=@./report.pdf' https://example.com/upload
# プロキシ経由
curl -x http://proxy:8080 https://example.com/
# 自己署名証明書許容 (デバッグ用)
curl -k https://localhost:8443/
wget の例
wget https://example.com/file.zip
wget -O - https://example.com/api | jq . # 標準出力
wget --mirror --convert-links https://example.com/ # サイト全体取得
関連ツール
| ツール | 用途 |
|---|
| curl / wget | CLI HTTP クライアント |
| HTTPie | http GET example.com。色付き・JSON 自動整形 |
| Postman / Insomnia | GUI API クライアント |
| Chrome DevTools / Firefox DevTools | Network タブで HTTP 観測 |
| Wireshark | HTTP/1.1 (平文) や HTTP/2 の解析 |
| mitmproxy | HTTP プロキシで中身改変 / 観測 |
REST API と HTTP
REST (Representational State Transfer) は HTTP のセマンティクスを最大限活用した API 設計スタイル。
| 操作 | メソッド | URL 例 | ステータス |
|---|
| 一覧取得 | GET | /api/users | 200 |
| 個別取得 | GET | /api/users/1 | 200 / 404 |
| 作成 | POST | /api/users | 201 (Location ヘッダ) |
| 全置換 | PUT | /api/users/1 | 200 / 204 |
| 部分更新 | PATCH | /api/users/1 | 200 / 204 |
| 削除 | DELETE | /api/users/1 | 204 |
CORS (Cross-Origin Resource Sharing)
ブラウザは Same-Origin Policy で異なるオリジンへの JS リクエストを制限。CORS はサーバが「このオリジンからは許可」とヘッダで宣言する仕組み。
# Preflight (OPTIONS リクエスト、ブラウザが自動送信)
OPTIONS /api/data HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization, Content-Type
# 許可レスポンス
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 86400
FAQ
Q: HTTP/2 と HTTPS は必須セット？
A: 仕様上は HTTP/2 でも平文可ですが、ブラウザは HTTPS 必須。現実は「HTTP/2 = HTTPS 上」で運用されています。HTTP/3 は仕様上 HTTPS のみ。
Q: 302 と 307 の違いは？
A: 302 はクライアントによってメソッドが GET に変えられがち（歴史的バグ）、307/308 はメソッドを変えずにリダイレクト。新規実装は 307/308 推奨。301 と 308 は永続、302 と 307 は一時。
Q: REST と GraphQL の違いは？
A: REST は HTTP メソッド + URL でリソースを表現。GraphQL は単一エンドポイントにクエリ言語で取得項目を指定。HTTP の冪等性メリットは REST 寄り、過剰取得回避は GraphQL 寄り。
