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

Question

IT Interview Practice · Accepted Answer

Rate limiting beskytter serveren mot for mange requests; HTTP-caching unngår å gjenta arbeid for requests den allerede har besvart. Begge er standardisert i HTTP og begge er vesentlige for et produksjons-API i stor skala.

## Rate limiting

Serveren begrenser hvor mange requests en klient kan gjøre per vindu og returnerer **`429 Too Many Requests`** når grensen overskrides. Den kunngjør grensene via headere slik at en veloppdragen klient kan strupe seg selv:

```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 forteller klienten nøyaktig hvor lenge den skal vente. Vanlige algoritmer: **token bucket** (tillater bursts opp til en bucket-størrelse, fylles jevnt på — det vanlige valget), **sliding window**, og **fixed window** (enklest, men burstete ved vinduskanter). Nøkler er vanligvis per API-nøkkel, bruker eller IP, med tellere i Redis for en distribuert flåte.

## HTTP-caching

To komplementære mekanismer:

**1. Utløp (`Cache-Control`)** — serveren sier hvor lenge en response holder seg fersk, så klienten/CDN-en gjenbruker den med **ingen request i det hele tatt**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validering (`ETag` / conditional requests)** — når ferskhet er usikker, revaliderer klienten billig. Serveren merker en response med en **`ETag`** (et versjonsfingeravtrykk); klienten sender den tilbake i `If-None-Match`, og hvis den er uendret returnerer serveren **`304 Not Modified`** med **ingen 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 driver også **optimistisk samtidighet (optimistic concurrency)**: send `If-Match: "a1b2c3"` på en `PUT`, og serveren returnerer `412 Precondition Failed` hvis noen andre endret ressursen først — og forhindrer tapte oppdateringer.

## Hvorfor det er viktig

Sammen er dette hvordan et REST-API overlever skalering, så senior-intervjuere bruker dem til å sjekke driftsmodenhet. For rate limiting er signalet at du behandler det som en **samarbeidskontrakt** — eksponerer `RateLimit-*`- og `Retry-After`-headere slik at klienter trekker seg tilbake elegant i stedet for å hamre mot en vegg — og at du kan navngi en algoritme og hvor telleren bor (Redis, per nøkkel) i en distribuert utrulling. For caching er nøkkelinnsikten **to-lags-modellen**: utløp (`max-age`) eliminerer requesten helt, mens validering (`ETag`/`304`) gjør de uunngåelige requestene billige ved å hoppe over body-en. Å nevne at ETags gjør dobbelttjeneste for **optimistisk samtidighet** (`If-Match` → `412`) viser dypere beherskelse av HTTP-semantikk. Kandidater som forstår disse mekanismene er de som kan bygge API-er som holder seg raske og stabile under reell trafikk, som er nøyaktig det spørsmålet tester.

Rate limiting

HTTP-caching

Hvorfor det er viktig

Relaterte spørsmål