Hvordan fungerer rate limiting og HTTP-caching i en REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting beskytter serveren mod for mange requests; HTTP-caching undgår at gentage arbejde for requests, den allerede har besvaret. Begge er standardiseret i HTTP, og begge er væsentlige for en produktions-API ved skala.

## Rate limiting

Serveren begrænser, hvor mange requests en client må lave per vindue, og returnerer **`429 Too Many Requests`**, når det overskrides. Den annoncerer grænser via headers, så en velopdragen client kan selv-throttle:

```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`-headeren fortæller clienten præcis, hvor længe den skal vente. Almindelige algoritmer: **token bucket** (tillader bursts op til en bucket-størrelse, genopfyldes støt — det sædvanlige valg), **sliding window** og **fixed window** (enklest, men burstet ved vindueskanterne). Keys er som regel per API key, user eller IP, med tællere i Redis for en distribueret flåde.

## HTTP-caching

To komplementære mekanismer:

**1. Udløb (`Cache-Control`)** — serveren siger, hvor længe et response forbliver frisk, så clienten/CDN'et genbruger det **helt uden en request**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validering (`ETag` / conditional requests)** — når friskheden er usikker, revaliderer clienten billigt. Serveren mærker et response med en **`ETag`** (et versions-fingeraftryk); clienten sender den tilbage i `If-None-Match`, og hvis uændret returnerer serveren **`304 Not Modified`** **uden body**:

```http
GET /users/42 HTTP/1.1
If-None-Match: "a1b2c3"
```
```http
HTTP/1.1 304 Not Modified      ← tom body, sparer båndbredde
```

```text
Frisk (inden for max-age)  → serveres fra cache, 0 requests
Forældet, men ETag matcher → 304, lillebitte response, ingen re-render
Forældet og ændret         → 200 med ny body + ny ETag
```

ETags driver også **optimistic concurrency**: send `If-Match: "a1b2c3"` på en `PUT`, og serveren returnerer `412 Precondition Failed`, hvis en anden ændrede resourcen først — hvilket forhindrer tabte opdateringer.

## Hvorfor det betyder noget

Tilsammen er disse måden, en REST API overlever skala på, så senior-interviewere bruger dem til at tjekke driftsmæssig modenhed. For rate limiting er signalet, at du behandler det som en **samarbejdende kontrakt** — ved at eksponere `RateLimit-*`- og `Retry-After`-headers, så clients trækker sig elegant frem for at hamre ind i en mur — og at du kan navngive en algoritme og hvor tælleren bor (Redis, per key) i en distribueret deployment. For caching er den centrale indsigt **to-lags-modellen**: udløb (`max-age`) eliminerer requesten helt, mens validering (`ETag`/`304`) gør de uundgåelige requests billige ved at springe body'en over. At nævne, at ETags gør dobbelt tjeneste for **optimistic concurrency** (`If-Match` → `412`) viser dybere beherskelse af HTTP-semantik. Kandidater, der forstår disse mekanismer, er dem, der kan bygge APIs, som forbliver hurtige og stabile under reel trafik, hvilket er præcis, hvad spørgsmålet tester.

Rate limiting

HTTP-caching

Hvorfor det betyder noget

Relaterede spørgsmål