Rate limiting

Il rate limiting limita la frequenza con cui un client può chiamare un’API, ad esempio 100 richieste al minuto per API key. Le richieste oltre il limite vengono rifiutate finché la finestra non si azzera. Protegge il servizio da sovraccarico e abusi, impedisce che un client troppo rumoroso lasci senza risorse gli altri e rallenta attacchi come l’indovinare le password. Il limite di solito viene conteggiato per API key, utente, token o indirizzo IP.

Esempio

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30

{"error": "rate_limited", "message": "Try again in 30 seconds"}

429 Too Many Requests e Retry-After sono HTTP standard. Gli header che riportano la quota residua, come X-RateLimit-Limit, X-RateLimit-Remaining e X-RateLimit-Reset, sono una convenzione diffusa ma non un unico standard, quindi verifica cosa documenta la tua API.

Algoritmi comuni

• Fixed window (finestra fissa): conta le richieste per minuto di calendario. Semplice, ma un client può inviare una doppia raffica a cavallo del confine tra due finestre.
• Sliding window (finestra scorrevole): conta le richieste negli ultimi N secondi, attenuando quell’effetto di confine.
• Token bucket: i token si ricaricano a un ritmo costante e ogni richiesta ne consuma uno, il che consente brevi raffiche fino alla dimensione del bucket pur imponendo un tasso medio.

Cosa testare

• Il limite stesso: invia limite + 1 richieste e verifica che esattamente quella in più riceva 429.
• Ripristino: dopo Retry-After o il momento di reset, le richieste tornano a riuscire.
• Ambito: il traffico di un utente o di una key non deve consumare la quota di un altro. Verifica se i limiti si applicano per key, per utente o per IP, e se un client può aggirarli cambiando qualcosa di poco costoso.
• Endpoint sensibili: login, reset della password e verifica dell’OTP dovrebbero avere limiti più stretti delle normali letture.
• Formato della risposta: una richiesta rifiutata restituisce 429 con un body utile, non un 500 o una connessione appesa.
• Comportamento del client: i tuoi client rallentano e rispettano Retry-After invece di riprovare in un ciclo stretto.

Rate limit e la tua suite di test

I test API in parallelo e i test di carico possono far scattare limiti simili a quelli di produzione e fallire per motivi che non c’entrano con la modifica sotto test. Usa key dedicate o limiti più alti negli ambienti di test e, quando un test di carico deve misurare la capacità, assicurati di misurare il servizio e non il rate limiter.