Comment fonctionnent le rate limiting et le caching HTTP dans une API REST ?

Question

IT Interview Practice · Accepted Answer

Le rate limiting protège le serveur d'un trop grand nombre de requêtes ; le caching HTTP évite de répéter le travail pour des requêtes auxquelles il a déjà répondu. Les deux sont standardisés dans HTTP et tous deux essentiels pour une API de production à l'échelle.

## Rate limiting

Le serveur plafonne le nombre de requêtes qu'un client peut faire par fenêtre et retourne **`429 Too Many Requests`** en cas de dépassement. Il annonce les limites via des headers pour qu'un client bien élevé puisse s'auto-limiter :

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

Le header `Retry-After` indique au client exactement combien de temps attendre. Algorithmes courants : **token bucket** (autorise des bursts jusqu'à la taille du bucket, se recharge régulièrement — le choix habituel), **sliding window**, et **fixed window** (le plus simple mais en rafale aux bords de la fenêtre). Les clés sont généralement par API key, user, ou IP, avec des compteurs dans Redis pour un parc distribué.

## HTTP caching

Deux mécanismes complémentaires :

**1. Expiration (`Cache-Control`)** — le serveur indique combien de temps une réponse reste fraîche, de sorte que le client/CDN la réutilise **sans aucune requête** :
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validation (`ETag` / conditional requests)** — quand la fraîcheur est incertaine, le client revalide à moindre coût. Le serveur étiquette une réponse avec un **`ETag`** (une empreinte de version) ; le client le renvoie dans `If-None-Match`, et si rien n'a changé le serveur retourne **`304 Not Modified`** **sans body** :

```http
GET /users/42 HTTP/1.1
If-None-Match: "a1b2c3"
```
```http
HTTP/1.1 304 Not Modified      ← body vide, économise la bande passante
```

```text
Fraîche (dans max-age)     → servie depuis le cache, 0 requête
Périmée mais ETag concorde → 304, réponse minuscule, pas de re-rendu
Périmée et modifiée        → 200 avec nouveau body + nouveau ETag
```

Les ETags alimentent aussi la **concurrence optimiste (optimistic concurrency)** : envoyez `If-Match: "a1b2c3"` sur un `PUT`, et le serveur retourne `412 Precondition Failed` si quelqu'un d'autre a modifié la ressource en premier — évitant les mises à jour perdues (lost updates).

## Pourquoi c'est important

Ensemble, c'est ainsi qu'une API REST survit à l'échelle, donc les recruteurs seniors s'en servent pour vérifier la maturité opérationnelle. Pour le rate limiting, le signal est que vous le traitez comme un **contrat coopératif** — en exposant les headers `RateLimit-*` et `Retry-After` pour que les clients ralentissent gracieusement au lieu de foncer dans un mur — et que vous pouvez nommer un algorithme et l'endroit où vit le compteur (Redis, par clé) dans un déploiement distribué. Pour le caching, l'intuition clé est le **modèle à deux niveaux** : l'expiration (`max-age`) élimine entièrement la requête, tandis que la validation (`ETag`/`304`) rend les requêtes inévitables peu coûteuses en sautant le body. Mentionner que les ETags font double emploi pour la **concurrence optimiste** (`If-Match` → `412`) montre une maîtrise plus profonde de la sémantique HTTP. Les candidats qui comprennent ces mécanismes sont ceux qui peuvent construire des API qui restent rapides et stables sous un trafic réel, ce qui est exactement ce que la question teste.

Rate limiting

HTTP caching

Pourquoi c'est important

Questions connexes