Kako delujeta rate limiting in HTTP caching v REST API-ju?

Question

IT Interview Practice · Accepted Answer

Rate limiting ščiti strežnik pred preveč zahtevami; HTTP caching se izogne ponavljanju dela za zahteve, na katere je že odgovoril. Oba sta standardizirana v HTTP in oba sta bistvena za produkcijski API pri velikem obsegu.

## Rate limiting

Strežnik omeji, koliko zahtev sme odjemalec narediti na okno, in ob prekoračitvi vrne **`429 Too Many Requests`**. Omejitve oglašuje prek glav, da se dobro vzgojen odjemalec lahko sam upočasni:

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

Glava `Retry-After` odjemalcu pove natanko, kako dolgo naj čaka. Pogosti algoritmi: **token bucket** (dovoljuje sunke do velikosti vedra, se enakomerno polni — običajna izbira), **sliding window** in **fixed window** (najpreprostejši, a sunkovit na robovih okna). Ključi so običajno po API ključu, uporabniku ali IP, s števci v Redisu za porazdeljeno floto.

## HTTP caching

Dva dopolnjujoča se mehanizma:

**1. Potek (`Cache-Control`)** — strežnik pove, kako dolgo odgovor ostane svež, da ga odjemalec/CDN znova uporabi **brez zahteve sploh**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validacija (`ETag` / pogojne zahteve)** — kadar svežina ni gotova, odjemalec poceni znova preveri. Strežnik odgovor označi z **`ETag`** (prstni odtis verzije); odjemalec ga pošlje nazaj v `If-None-Match`, in če se ni spremenil, strežnik vrne **`304 Not Modified`** **brez telesa**:

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

ETag-i poganjajo tudi **optimistično sočasnost (optimistic concurrency)**: pošljite `If-Match: "a1b2c3"` na `PUT`, in strežnik vrne `412 Precondition Failed`, če je nekdo drug vir spremenil prej — s čimer prepreči izgubljene posodobitve.

## Zakaj je to pomembno

Skupaj sta to način, kako REST API preživi obseg, zato ju senior spraševalci uporabijo za preverjanje operativne zrelosti. Pri rate limitingu je signal, da ga obravnavate kot **sodelovalno pogodbo** — izpostavljate glave `RateLimit-*` in `Retry-After`, da se odjemalci gladko umaknejo, namesto da bi butali v zid — in da znate poimenovati algoritem ter kje živi števec (Redis, po ključu) v porazdeljeni namestitvi. Pri predpomnjenju je ključni uvid **dvonivojski model**: potek (`max-age`) povsem odpravi zahtevo, medtem ko validacija (`ETag`/`304`) neizogibne zahteve poceni s preskokom telesa. Omemba, da ETag-i opravljajo dvojno delo za **optimistično sočasnost** (`If-Match` → `412`), pokaže globlje obvladovanje semantike HTTP. Kandidati, ki razumejo te mehanizme, so tisti, ki znajo graditi API-je, ki ostanejo hitri in stabilni pod resničnim prometom, kar je natanko to, kar vprašanje preverja.

Rate limiting

HTTP caching

Zakaj je to pomembno

Povezana vprašanja