Kako funkcioniraju rate limiting i HTTP cachiranje u REST API-ju?

Question

IT Interview Practice · Accepted Answer

Rate limiting štiti server od previše zahtjeva; HTTP cachiranje izbjegava ponavljanje posla za zahtjeve na koje je već odgovorio. Oba su standardizirana u HTTP-u i oba su bitna za produkcijski API pri velikoj skali.

## Rate limiting

Server ograničava koliko zahtjeva klijent smije napraviti po prozoru i vraća **`429 Too Many Requests`** kad se prekorači. Objavljuje limite kroz headere kako bi se dobro ponašajući klijent mogao sam pridušiti:

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

Header `Retry-After` govori klijentu točno koliko dugo čekati. Uobičajeni algoritmi: **token bucket** (dopušta rafale do veličine bucketa, ravnomjerno se puni — uobičajeni izbor), **sliding window** i **fixed window** (najjednostavniji, ali s rafalima na rubovima prozora). Ključevi su obično po API ključu, korisniku ili IP-u, s brojačima u Redisu za distribuiranu flotu.

## HTTP cachiranje

Dva komplementarna mehanizma:

**1. Istek (`Cache-Control`)** — server kaže koliko dugo odgovor ostaje svjež, pa ga klijent/CDN ponovno koristi **bez ikakvog zahtjeva**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validacija (`ETag` / uvjetni zahtjevi)** — kad je svježina neizvjesna, klijent jeftino revalidira. Server označi odgovor **`ETag`-om** (otisak verzije); klijent ga vraća u `If-None-Match`, i ako je nepromijenjen server vraća **`304 Not Modified`** **bez tijela**:

```http
GET /users/42 HTTP/1.1
If-None-Match: "a1b2c3"
```
```http
HTTP/1.1 304 Not Modified      ← prazno tijelo, štedi propusnost
```

```text
Svjež (unutar max-age)     → posluženo iz cachea, 0 zahtjeva
Zastario ali ETag odgovara → 304, sićušan odgovor, bez ponovnog renderiranja
Zastario i promijenjen     → 200 s novim tijelom + novim ETagom
```

ETagovi također pokreću **optimistic concurrency**: pošaljite `If-Match: "a1b2c3"` na `PUT`, a server vraća `412 Precondition Failed` ako je netko drugi prvi promijenio resurs — sprječavajući izgubljena ažuriranja (lost updates).

## Zašto je to važno

Zajedno, ovo je način na koji REST API preživljava skalu, pa ih senior ispitivači koriste za provjeru operativne zrelosti. Za rate limiting, signal je da ga tretirate kao **kooperativni ugovor** — izlažući `RateLimit-*` i `Retry-After` headere kako bi klijenti graciozno usporili umjesto da udaraju u zid — i da možete imenovati algoritam te gdje brojač živi (Redis, po ključu) u distribuiranom deploymentu. Za cachiranje, ključni uvid je **dvoslojni model**: istek (`max-age`) potpuno eliminira zahtjev, dok validacija (`ETag`/`304`) čini neizbježne zahtjeve jeftinima preskačući tijelo. Spominjanje da ETagovi dvostruko služe za **optimistic concurrency** (`If-Match` → `412`) pokazuje dublje vladanje HTTP semantikom. Kandidati koji razumiju ove mehanizme oni su koji mogu graditi API-je koji ostaju brzi i stabilni pod stvarnim prometom, što je upravo ono što pitanje ispituje.

Rate limiting

HTTP cachiranje

Zašto je to važno

Povezana pitanja