Hoe werken rate limiting en HTTP-caching in een REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting beschermt de server tegen te veel requests; HTTP-caching voorkomt het herhalen van werk voor requests die al beantwoord zijn. Beide zijn gestandaardiseerd in HTTP en beide zijn essentieel voor een productie-API op schaal.

## Rate limiting

De server begrenst hoeveel requests een client per venster mag doen en retourneert **`429 Too Many Requests`** bij overschrijding. Hij adverteert limieten via headers zodat een net gedragende client zichzelf kan afknijpen:

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

De `Retry-After`-header vertelt de client precies hoe lang hij moet wachten. Gangbare algoritmen: **token bucket** (staat bursts toe tot een bucket-grootte, vult gestaag bij — de gebruikelijke keuze), **sliding window**, en **fixed window** (eenvoudigst maar bursterig aan de vensterranden). Sleutels zijn meestal per API-key, user of IP, met counters in Redis voor een gedistribueerde fleet.

## HTTP-caching

Twee complementaire mechanismen:

**1. Vervaltijd (`Cache-Control`)** — de server zegt hoe lang een response vers blijft, zodat de client/CDN hem hergebruikt met **helemaal geen request**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validatie (`ETag` / conditional requests)** — wanneer de versheid onzeker is, hervalideert de client goedkoop. De server tagt een response met een **`ETag`** (een versie-vingerafdruk); de client stuurt hem terug in `If-None-Match`, en als er niets is veranderd retourneert de server **`304 Not Modified`** **zonder body**:

```http
GET /users/42 HTTP/1.1
If-None-Match: "a1b2c3"
```
```http
HTTP/1.1 304 Not Modified      ← empty body, saves bandwidth
```

```text
Fresh (within max-age)   → served from cache, 0 requests
Stale but ETag matches   → 304, tiny response, no re-render
Stale and changed        → 200 with new body + new ETag
```

ETags voeden ook **optimistic concurrency**: stuur `If-Match: "a1b2c3"` bij een `PUT`, en de server retourneert `412 Precondition Failed` als iemand anders de resource eerst wijzigde — wat lost updates voorkomt.

## Waarom het belangrijk is

Samen zijn dit hoe een REST API schaal overleeft, dus senior-interviewers gebruiken ze om operationele volwassenheid te checken. Voor rate limiting is het signaal dat je het als een **coöperatief contract** behandelt — `RateLimit-*`- en `Retry-After`-headers blootstellen zodat clients netjes terugschakelen in plaats van tegen een muur te beuken — en dat je een algoritme kunt noemen en waar de counter leeft (Redis, per key) in een gedistribueerde deployment. Voor caching is het kerninzicht het **tweelaagsmodel**: vervaltijd (`max-age`) elimineert de request volledig, terwijl validatie (`ETag`/`304`) de onvermijdelijke requests goedkoop maakt door de body over te slaan. Vermelden dat ETags dubbel dienstdoen voor **optimistic concurrency** (`If-Match` → `412`) toont diepere beheersing van de HTTP-semantiek. Kandidaten die deze mechanismen begrijpen zijn degenen die API's kunnen bouwen die snel en stabiel blijven onder echt verkeer, precies wat de vraag test.

Rate limiting

HTTP-caching

Waarom het belangrijk is

Gerelateerde vragen