Miten rate limiting ja HTTP-cachetus toimivat REST API:ssa?

Question

IT Interview Practice · Accepted Answer

Rate limiting suojaa palvelinta liialta pyyntömäärältä; HTTP-cachetus välttää työn toistamista pyynnöille, joihin se on jo vastannut. Molemmat on standardoitu HTTP:ssä ja molemmat ovat olennaisia tuotanto-API:lle mittakaavassa.

## Rate limiting

Palvelin rajaa, kuinka monta pyyntöä client saa tehdä per aikaikkuna, ja palauttaa **`429 Too Many Requests`**, kun raja ylitetään. Se ilmoittaa rajat headereilla, jotta hyvin käyttäytyvä client voi itseään hillitä:

```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`-header kertoo clientille tarkalleen, kuinka kauan odottaa. Yleiset algoritmit: **token bucket** (sallii burstit bucketin kokoon asti, täyttyy tasaisesti — tavallinen valinta), **sliding window** ja **fixed window** (yksinkertaisin mutta burstaava ikkunan reunoilla). Avaimet ovat yleensä per API-avain, käyttäjä tai IP, laskureineen Redisissä hajautetulle klusterille.

## HTTP-cachetus

Kaksi toisiaan täydentävää mekanismia:

**1. Vanheneminen (`Cache-Control`)** — palvelin kertoo, kuinka kauan vastaus pysyy tuoreena, joten client/CDN käyttää sitä uudelleen **ilman pyyntöä lainkaan**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validointi (`ETag` / conditional requests)** — kun tuoreus on epävarma, client revalidoi halvalla. Palvelin merkitsee vastauksen **`ETag`**illa (versiosormenjälki); client lähettää sen takaisin `If-None-Match`issa, ja jos se ei ole muuttunut, palvelin palauttaa **`304 Not Modified`** **ilman 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
```

ETagit tehostavat myös **optimistic concurrencya**: lähetä `If-Match: "a1b2c3"` `PUT`issa, ja palvelin palauttaa `412 Precondition Failed`, jos joku muu muutti resurssia ensin — estäen kadonneet päivitykset.

## Miksi se on tärkeää

Yhdessä nämä ovat se, miten REST API selviää mittakaavasta, joten senior-haastattelijat käyttävät niitä tarkistaakseen operatiivisen kypsyyden. Rate limitingissä signaali on, että kohtelet sitä **yhteistoiminnallisena sopimuksena** — paljastaen `RateLimit-*`- ja `Retry-After`-headerit, jotta clientit perääntyvät sulavasti sen sijaan että hakkaisivat seinään — ja että osaat nimetä algoritmin ja missä laskuri sijaitsee (Redis, per avain) hajautetussa deploymentissa. Cachetuksessa keskeinen oivallus on **kaksitasoinen malli**: vanheneminen (`max-age`) eliminoi pyynnön kokonaan, kun taas validointi (`ETag`/`304`) tekee väistämättömistä pyynnöistä halpoja bodyn ohittamalla. Sen mainitseminen, että ETagit tekevät kaksoistyötä **optimistic concurrencyssa** (`If-Match` → `412`), osoittaa syvempää HTTP-semantiikan hallintaa. Ehdokkaat, jotka ymmärtävät nämä mekanismit, ovat niitä, jotka osaavat rakentaa API:ja, jotka pysyvät nopeina ja vakaina todellisen liikenteen alla, mikä on juuri se, mitä kysymys testaa.

Rate limiting

HTTP-cachetus

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset