Jak fungují rate limiting a HTTP cachování v REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting chrání server před příliš mnoha požadavky; HTTP cachování se vyhýbá opakování práce u požadavků, které už zodpovědělo. Obojí je standardizované v HTTP a obojí je nezbytné pro produkční API ve velkém.

## Rate limiting

Server omezuje, kolik požadavků smí klient udělat za časové okno, a při překročení vrací **`429 Too Many Requests`**. Limity oznamuje přes hlavičky, aby se slušně vychovaný klient mohl sám přiškrtit:

```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" }
```

Hlavička `Retry-After` říká klientovi přesně, jak dlouho čekat. Běžné algoritmy: **token bucket** (dovolí burst až do velikosti bucketu, doplňuje se rovnoměrně — obvyklá volba), **sliding window** a **fixed window** (nejjednodušší, ale s burstem na okrajích okna). Klíče jsou obvykle podle API klíče, uživatele nebo IP, s čítači v Redis pro distribuovanou flotilu.

## HTTP cachování

Dva doplňující se mechanismy:

**1. Expirace (`Cache-Control`)** — server říká, jak dlouho zůstává odpověď čerstvá, takže ji klient/CDN znovu použije **bez jakéhokoli požadavku**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validace (`ETag` / podmíněné požadavky)** — když je čerstvost nejistá, klient levně revaliduje. Server označí odpověď pomocí **`ETag`** (otisk verze); klient jej pošle zpět v `If-None-Match`, a pokud se nezměnil, server vrátí **`304 Not Modified`** **bez těla**:

```http
GET /users/42 HTTP/1.1
If-None-Match: "a1b2c3"
```
```http
HTTP/1.1 304 Not Modified      ← prázdné tělo, šetří šířku pásma
```

```text
Čerstvé (v rámci max-age)  → obslouženo z cache, 0 požadavků
Zastaralé, ale ETag sedí   → 304, drobná odpověď, žádné re-render
Zastaralé a změněné        → 200 s novým tělem + novým ETag
```

ETagy také pohánějí **optimistickou souběžnost (optimistic concurrency)**: pošlete `If-Match: "a1b2c3"` u `PUT` a server vrátí `412 Precondition Failed`, pokud zdroj někdo jiný změnil dřív — což zabraňuje ztraceným aktualizacím (lost updates).

## Proč je to důležité

Dohromady je to způsob, jak REST API přežije velký provoz, takže senior tazatelé je používají ke kontrole provozní vyzrálosti. U rate limitingu je signálem, že ho berete jako **kooperativní kontrakt** — vystavujete hlavičky `RateLimit-*` a `Retry-After`, aby klienti elegantně ustoupili místo bušení do zdi — a že umíte pojmenovat algoritmus a kde čítač žije (Redis, podle klíče) v distribuovaném nasazení. U cachování je klíčovým poznatkem **dvouúrovňový model**: expirace (`max-age`) požadavek úplně eliminuje, zatímco validace (`ETag`/`304`) činí nevyhnutelné požadavky levnými tím, že vynechá tělo. Zmínka, že ETagy plní dvojí roli pro **optimistickou souběžnost** (`If-Match` → `412`), ukazuje hlubší zvládnutí sémantiky HTTP. Kandidáti, kteří těmto mechanismům rozumí, jsou ti, kdo dokážou stavět API, jež zůstávají rychlá a stabilní pod skutečným provozem, což je přesně to, co otázka testuje.

Rate limiting

HTTP cachování

Proč je to důležité

Související otázky