Come funzionano il rate limiting e il caching HTTP in un’API REST?

Question

IT Interview Practice · Accepted Answer

Il rate limiting protegge il server da troppe richieste; il caching HTTP evita di ripetere lavoro per richieste a cui ha già risposto. Entrambi sono standardizzati in HTTP ed entrambi sono essenziali per un'API di produzione su larga scala.

## Rate limiting

Il server limita quante richieste un client può fare per finestra e restituisce **`429 Too Many Requests`** quando viene superato. Pubblicizza i limiti tramite header così che un client ben educato possa auto-limitarsi:

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

L'header `Retry-After` dice al client esattamente quanto aspettare. Algoritmi comuni: **token bucket** (consente burst fino alla dimensione del bucket, si ricarica costantemente — la scelta abituale), **sliding window** e **fixed window** (il più semplice ma soggetto a burst ai bordi della finestra). Le chiavi sono di solito per API key, utente o IP, con contatori in Redis per un parco distribuito.

## Caching HTTP

Due meccanismi complementari:

**1. Scadenza (`Cache-Control`)** — il server dice per quanto tempo una risposta resta fresca, così che client/CDN la riutilizzino con **nessuna richiesta affatto**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validazione (`ETag` / conditional request)** — quando la freschezza è incerta, il client rivalida a basso costo. Il server marca una risposta con un **`ETag`** (un'impronta di versione); il client lo rimanda in `If-None-Match`, e se non è cambiato il server restituisce **`304 Not Modified`** con **nessun 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
```

Gli ETag alimentano anche la **concorrenza ottimistica**: invia `If-Match: "a1b2c3"` su un `PUT`, e il server restituisce `412 Precondition Failed` se qualcun altro ha modificato la risorsa prima — prevenendo aggiornamenti persi.

## Perché è importante

Insieme, questi sono il modo in cui un'API REST sopravvive alla scala, quindi gli intervistatori senior li usano per verificare la maturità operativa. Per il rate limiting, il segnale è che lo tratti come un **contratto cooperativo** — esponendo gli header `RateLimit-*` e `Retry-After` così che i client facciano back off con grazia anziché sbattere contro un muro — e che sai nominare un algoritmo e dove vive il contatore (Redis, per chiave) in un deployment distribuito. Per il caching, l'intuizione chiave è il **modello a due livelli**: la scadenza (`max-age`) elimina del tutto la richiesta, mentre la validazione (`ETag`/`304`) rende economiche le richieste inevitabili saltando il body. Menzionare che gli ETag fanno doppio servizio per la **concorrenza ottimistica** (`If-Match` → `412`) mostra una padronanza più profonda della semantica HTTP. I candidati che capiscono questi meccanismi sono quelli che sanno costruire API che restano veloci e stabili sotto traffico reale, che è esattamente ciò che la domanda sta testando.

Rate limiting

Caching HTTP

Perché è importante

Domande correlate