Hur fungerar rate limiting och HTTP-caching i ett REST-API?

Question

IT Interview Practice · Accepted Answer

Rate limiting skyddar servern från för många requests; HTTP-caching undviker att upprepa arbete för requests den redan besvarat. Båda är standardiserade i HTTP och båda är väsentliga för ett produktions-API vid skala.

## Rate limiting

Servern begränsar hur många requests en client får göra per fönster och returnerar **`429 Too Many Requests`** vid överskridande. Den annonserar gränser via headers så att en välartad client kan självstrypa:

```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`-headern talar om för client:en exakt hur länge den ska vänta. Vanliga algoritmer: **token bucket** (tillåter bursts upp till en bucket-storlek, fyller på stadigt — det vanliga valet), **sliding window**, och **fixed window** (enklast men burstig vid fönsterkanterna). Nycklar är oftast per API key, user, eller IP, med räknare i Redis för en distribuerad flotta.

## HTTP-caching

Två kompletterande mekanismer:

**1. Expiration (`Cache-Control`)** — servern säger hur länge en response förblir färsk, så att client:en/CDN:en återanvänder den med **ingen request alls**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validation (`ETag` / conditional requests)** — när färskhet är osäker revaliderar client:en billigt. Servern taggar en response med en **`ETag`** (ett versionsfingeravtryck); client:en skickar tillbaka den i `If-None-Match`, och om oförändrad returnerar servern **`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
Färsk (inom max-age)       → serveras från cache, 0 requests
Föråldrad men ETag matchar → 304, litet svar, ingen omrendering
Föråldrad och ändrad       → 200 med ny body + ny ETag
```

ETags driver också **optimistic concurrency**: skicka `If-Match: "a1b2c3"` på en `PUT`, och servern returnerar `412 Precondition Failed` om någon annan ändrade resursen först — vilket förhindrar förlorade uppdateringar.

## Varför det är viktigt

Tillsammans är dessa hur ett REST-API överlever skala, så seniora intervjuare använder dem för att kontrollera driftsmognad. För rate limiting är signalen att du behandlar det som ett **kooperativt kontrakt** — att exponera `RateLimit-*`- och `Retry-After`-headers så att clients backar av graciöst i stället för att hamra mot en vägg — och att du kan namnge en algoritm och var räknaren bor (Redis, per key) i en distribuerad deployment. För caching är den centrala insikten **tvånivåmodellen**: expiration (`max-age`) eliminerar request:en helt, medan validation (`ETag`/`304`) gör de oundvikliga requests billiga genom att hoppa över body:n. Att nämna att ETags gör dubbel tjänst för **optimistic concurrency** (`If-Match` → `412`) visar djupare behärskning av HTTP-semantik. Kandidater som förstår dessa mekanismer är de som kan bygga API:er som förblir snabba och stabila under verklig trafik, vilket är precis vad frågan testar.

Rate limiting

HTTP-caching

Varför det är viktigt

Relaterade frågor