Cos'è la limitazione della frequenza?

La limitazione della frequenza è un meccanismo di controllo usato dalle API cloud per regolare il numero di richieste che un utente può effettuare in un momento specifico. I produttori di API cloud usano la limitazione della frequenza per garantire che il flusso delle richieste non sovraccarici il servizio. La limitazione della frequenza imposta un limite per la velocità e il volume delle chiamate API. I limiti di frequenza vengono in genere definiti in termini di richieste per periodo di tempo.

Perché le API cloud usano la limitazione della frequenza

  • Impedire l'overload. La limitazione della frequenza garantisce che il server API rimanga stabile e reattivo impedendo a qualsiasi singolo utente o servizio di inondarlo con troppe richieste.
  • Garantire un utilizzo equo. La limitazione della frequenza applica criteri di utilizzo equi, assicurandosi che nessun singolo utente monopolizzi le risorse API. La limitazione della velocità consente l'accesso equo a tutti gli utenti.
  • Aumentare la sicurezza. La limitazione della frequenza consente di mitigare gli attacchi Denial of Service distribuiti e altri comportamenti offensivi limitando il numero di richieste da origini potenzialmente dannose.
  • Gestire i costi. Per i provider di servizi cloud, la limitazione della velocità consente di gestire i costi operativi impedendo un uso imprevedibile o eccessivo delle risorse.
  • Mantenere la qualità del servizio. La limitazione della frequenza garantisce una qualità coerente del servizio per tutti gli utenti impedendo i picchi di traffico.

Come si sperimenta la limitazione della velocità nelle tue app

Quando si compilano app che integrano le API cloud, controllare la relativa documentazione per verificare se supportano la limitazione della frequenza. In tal caso, si ricevono intestazioni di risposta RateLimit-... o X-RateLimit-... con informazioni sui limiti di velocità. È possibile usare queste informazioni nell'applicazione per assicurarsi di non superare i limiti di frequenza dell'API. Ad esempio, l'intestazione RateLimit-Remaining indica il numero di richieste rimanenti nella finestra corrente. Se si riceve una risposta con questa intestazione impostata su 0, si è certi di aver raggiunto il limite di velocità e di attendere la finestra successiva prima di inviare un'altra richiesta. L'intestazione RateLimit-Reset indica l'ora in cui il limite di velocità viene reimpostato. Alcune API inviano le RateLimit-... intestazioni solo dopo aver raggiunto una soglia. Un esempio è quando ti restano 10% di richieste.

Quando si supera il limite di frequenza, l'API limita le richieste e restituisce un codice di stato HTTP 429 Too Many Requests . Alcune API potrebbero anche inviare un'intestazione Retry-After per indicare per quanto tempo è necessario attendere prima di inviare un'altra richiesta. Non tutte le API seguono questo modello. GitHub, ad esempio, può rispondere con 403 anziché 429.

Per evitare limitazioni e assicurarsi che l'applicazione rimanga reattiva, implementare la limitazione della velocità nell'applicazione. A seconda dello stack di tecnologie, librerie diverse consentono di gestire la limitazione della frequenza nell'applicazione. Dopo aver implementato la limitazione della frequenza nell'applicazione, verificare se gestisce correttamente la limitazione della frequenza.

In che modo la limitazione della frequenza influisce sull'app?

Quando un'API inizia a restituire 429 risposte, un'app che non le gestisce si arresta in modo anomalo, visualizza un errore generico, riprova così velocemente che rimane soggetta a limitazione o scarta silenziosamente i dati. Raramente viene visualizzato nulla di tutto questo durante lo sviluppo, perché l'API è veloce, sei l'unico utente e i dati di test sono di piccole dimensioni.

Come testare che l'app gestisca i limiti di frequenza

Avvicinarsi Cosa trovi Quello che ti manca
Attendere l'ambiente di produzione Limiti di frequenza effettivi Tutto, fino a quando un utente non ci fa clic
Simula l'API nei test o consenti all'agente di codifica di scrivere il mock Se il ramo di ripetizione dei tentativi viene eseguito Codici di stato reali dell'API, intestazioni del limite di frequenza e corpi degli errori e politica di retry dell'SDK. L'app richiede anche un interruttore solo per test per raggiungere il mock.
Chiamare l'API reale fino a quando non ti limita Comportamento reale Non puoi raggiungere il limite a piacimento, usi la tua quota reale e alcuni limiti vengono reimpostati solo dopo un'ora
Intercettare il traffico reale dell'app e simulare il limite URL reali, l'SDK effettivo, la politica di retry e le intestazioni dell'API, con un limite scelto da te Il tuo codice in modo autonomo. Mantieni gli unit test per quello.

Provala nella tua app

Dev Proxy conta le richieste dell'app alle API scelte, aggiunge intestazioni limite di frequenza alle risposte e restituisce 429 quando l'app supera il limite, mentre l'app continua a chiamare gli URL reali. Indica anche quando l'app chiama nuovamente l'API prima della reimpostazione del limite.

Scaricare il set di impostazioni per l'API che l'app chiama e avviare Dev Proxy con esso:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

Per le chiamate Microsoft Graph a OneDrive e SharePoint (/drive, /shares, /sites), usare la preimpostazione microsoft-graph-rate-limiting. Per impostare un limite personalizzato per qualsiasi API, vedere Simulare le risposte API per il rate limit. Per installare Dev Proxy, vedere Configurare Dev Proxy.

Passaggi successivi

Come gestire la limitazione della frequenza

  • Last updated on