面接頻出REST APIの4大概念：冪等性・PUT vs PATCH・ページネーション・レートリミット
概要¶
REST API 面接で最もよく問われる4つの概念をまとめて整理。
詳細¶
1. HTTP メソッドの冪等性（Idempotency）¶
冪等 = 同じリクエストを何度送っても結果が変わらない こと。
| メソッド | 冪等 | 安全（副作用なし） | 用途 |
|---|---|---|---|
| GET | ✓ | ✓ | 取得 |
| HEAD | ✓ | ✓ | ヘッダのみ取得 |
| PUT | ✓ | ✗ | リソース全体を置き換え |
| DELETE | ✓ | ✗ | 削除（2回目は 404 だが状態は変わらない） |
| POST | ✗ | ✗ | 作成（毎回新しいリソースが生まれる） |
| PATCH | ✗ | ✗ | 部分更新（設計次第で冪等にもできる） |
2. PUT vs PATCH¶
# PUT: リソース全体を置き換える（全フィールドが必要）
PUT /users/123
{"name": "Alice", "email": "alice@new.com", "role": "admin"}
# PATCH: 指定フィールドだけ更新
PATCH /users/123
{"email": "alice@new.com"}
3. Pagination・Filtering・Versioning¶
# Offset Pagination（シンプルだが大規模では性能劣化）
GET /posts?page=3&limit=20
# Cursor Pagination（推奨：大量データでも安定・重複なし）
GET /posts?after=eyJpZCI6MTAwfQ&limit=20
# Filtering
GET /products?category=electronics&status=active&price_max=1000
# Versioning（破壊的変更を安全に行うため）
GET /api/v1/users → 旧クライアント向け（維持）
GET /api/v2/users → 新クライアント向け（変更あり）
4. Rate Limiting & Throttling¶
# ヘッダでクライアントに状況を伝える
X-RateLimit-Limit: 100 # 1時間あたりの上限
X-RateLimit-Remaining: 20 # 残り回数
X-RateLimit-Reset: 1699200000 # リセット時刻（Unix時刻）
# 超過時のレスポンス
HTTP 429 Too Many Requests
Retry-After: 3600
Rate Limit のアルゴリズム: - Token Bucket: バケツにトークンが補充され、リクエストのたびに消費 - Sliding Window: 直近N秒のリクエスト数を計算（実装は Redis + Sorted Set） - Fixed Window: 固定時間帯ごとにカウンター（実装が最もシンプル）
なぜ重要か / いつ使うか¶
- REST API の面接問題は必ずこの4カテゴリから出題される
- API 設計レビューで「この実装で良いか」の判断基準として