REST API で rate limiting と HTTP caching はどう機能しますか?

Question

IT Interview Practice · Accepted Answer

Rate limiting は server を過剰なリクエストから守り、HTTP caching はすでに答えたリクエストの作業の繰り返しを避けます。どちらも HTTP で標準化され、規模の大きい production API に不可欠です。

## Rate limiting

server は、client が各時間窓で行えるリクエスト数に上限を設け、超過時に **`429 Too Many Requests`** を返します。行儀の良い client が自己スロットリングできるよう、ヘッダで上限を広告します:

```http
HTTP/1.1 200 OK
RateLimit-Limit: 100
RateLimit-Remaining: 12
RateLimit-Reset: 30
```

```http
HTTP/1.1 429 Too Many Requests
Retry-After: 30

{ "error": "rate limit exceeded, retry in 30s" }
```

`Retry-After` ヘッダは client にどれだけ待つべきか正確に伝えます。一般的なアルゴリズム: **token bucket** (バケットサイズまでのバーストを許し、一定に補充する — 通常の選択)、**sliding window**、**fixed window** (最も単純だが窓の端でバースト的)。key は通常 API key、user、または IP ごとで、分散フリートでは Redis のカウンタを使います。

## HTTP caching

2 つの補完的な機構:

**1. 有効期限 (`Cache-Control`)** — server はレスポンスがどれだけ新鮮なままか告げ、client/CDN が **リクエストなしで** 再利用します:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. 検証 (`ETag` / 条件付きリクエスト)** — 新鮮さが不確かなとき、client は安価に再検証します。server はレスポンスに **`ETag`** (バージョンの指紋) をタグ付けし、client はそれを `If-None-Match` で送り返し、変わっていなければ server は **`304 Not Modified`** を **body なし** で返します:

```http
GET /users/42 HTTP/1.1
If-None-Match: "a1b2c3"
```
```http
HTTP/1.1 304 Not Modified      ← body なし、帯域を節約
```

```text
新鮮 (max-age 内)        → cache から提供、0 リクエスト
古いが ETag が一致        → 304、極小の response、再レンダリングなし
古くて変更あり            → 新しい body + 新しい ETag 付きの 200
```

ETag は **楽観的並行性制御 (optimistic concurrency)** にも力を与えます: `PUT` で `If-Match: "a1b2c3"` を送り、他の誰かが先にリソースを変更していれば server は `412 Precondition Failed` を返します — 更新の喪失を防ぎます。

## なぜ重要なのか

両者は REST API が規模を生き延びる方法なので、シニアの面接官はこれで運用の成熟度を確認します。rate limiting では、シグナルはあなたがそれを **協力的な契約** として扱うこと — `RateLimit-*` と `Retry-After` ヘッダを公開し、client が壁に激突するのでなく優雅にバックオフできるようにする — と、分散デプロイでアルゴリズムとカウンタの置き場所 (Redis、key ごと) を挙げられることです。caching では、鍵となる洞察は **2 層モデル** です: 有効期限 (`max-age`) はリクエストを完全に排除し、検証 (`ETag`/`304`) は避けられないリクエストを body を飛ばして安価にします。ETag が **楽観的並行性制御** (`If-Match` → `412`) を兼任すると述べることは、HTTP セマンティクスへのより深い習熟を示します。これらの機構を理解する候補者こそ、現実のトラフィック下で高速で安定した API を作れる人であり、それがまさにこの質問が試していることです。

Rate limiting

HTTP caching

なぜ重要なのか

関連する質問