この記事の要点

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 寄り。