Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
La limitazione della frequenza è una tecnica comune usata dai provider di API per gestire il numero di richieste che possono essere effettuate al servizio in un periodo di tempo specifico. I provider di API usano la limitazione della frequenza per garantire che il servizio rimanga disponibile e reattivo a tutti gli utenti e per evitare abusi o uso eccessivo del servizio.
Quando si usano le API cloud nell'applicazione, è necessario comprendere i limiti di frequenza. Le tecniche seguenti consentono di gestire la limitazione della frequenza nelle applicazioni:
- Comprendere i limiti di frequenza. Consultare la documentazione dell'API usata per comprendere i limiti di frequenza. I limiti di frequenza possono dipendere dal provider di API o dal piano di servizio usato. Ad esempio, alcune API potrebbero avere limiti di tariffa diversi per i piani gratuiti e a pagamento.
- Usare le informazioni sulla limitazione della frequenza. Le API che usano limiti di frequenza comunicano in genere i limiti correnti nelle intestazioni di risposta. Ad esempio, l'intestazione
RateLimit-Remainingindica il numero di richieste che rimangono 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'intestazioneRateLimit-Resetindica l'ora di reimpostazione del limite di velocità. I nomi e i formati di intestazione variano in base all'API: GitHub, ad esempio, usax-ratelimit-remainingex-ratelimit-resetin secondi dell'epoca UTC. Alcune API inviano le intestazioni solo dopo aver raggiunto una soglia. Un esempio è quando ti restano 10% di richieste. - Ottimizzare l'utilizzo dell'API. Alcuni servizi assegnano costi diversi a richieste diverse in base alla loro complessità. Ad esempio, alcune API potrebbero addebitare più addebiti per le richieste che restituiscono più dati. Per ridurre il costo dell'applicazione, ottimizzare l'utilizzo dell'API recuperando solo i dati necessari. Usare le richieste batch se l'API le supporta. Consentono di ridurre il numero di risorse necessarie per elaborare la risposta e rimanere entro i limiti di velocità.
- Implementare un limite di velocità locale. Implementare un limite di velocità all'interno dell'applicazione stessa per limitare il numero di richieste che possono essere effettuate all'API in un periodo di tempo specifico. È possibile farlo usando tecniche quali bucket dei token o algoritmi a goccia, che consentono all'applicazione di effettuare molte richieste per un determinato periodo di tempo. Qualsiasi altra richiesta viene accodata o eliminata.
- Evitare di superare i limiti di velocità. Quando si superano i limiti di frequenza, l'API limita le richieste, in genere con un codice di stato HTTP
429 Too Many Requests. Il throttling influisce sulla velocità effettiva dell'applicazione più del rate limiting. Usare le informazioni negli header di risposta del rate limit per rimanere entro i limiti ed evitare il throttling.
Usando queste tecniche, è possibile compilare applicazioni resilienti alla limitazione della frequenza e continuare a funzionare anche quando l'API è sotto carico elevato. Quindi verificare che lo facciano, perché raramente si raggiunge un limite di frequenza durante lo sviluppo.
Come testare la gestione dei 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 oppure consenti all'agente di programmazione di scrivere il mock | Se il codice legge le intestazioni fittizie | I nomi, i formati e il comportamento di reimpostazione degli header effettivi dell'API e il criterio di retry dell'SDK. L'app richiede anche uno switch solo di test per raggiungere il mock. |
| Chiama l'API reale finché non raggiungi il limite | 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, intervallo di tempo e limite scelto e intestazioni proprie dell'API | Il tuo codice, isolatamente. Tieni i tuoi unit test per quello. |
Provalo nella tua app
Dev Proxy conta le richieste dell'app alle API scelte, aggiunge intestazioni limite di frequenza alle risposte e risponde con 429 quando l'app supera il limite, mentre l'app continua a chiamare gli URL reali. È possibile scegliere il limite e l'intervallo di tempo, in modo da poterlo raggiungere in un minuto invece di un'ora.
Per GitHub, scaricare il set di impostazioni 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 installare Dev Proxy, vedere Configurare Dev Proxy.
Passo successivo
Collabora con noi su GitHub
L'origine di questo contenuto è disponibile in GitHub, in cui è anche possibile creare ed esaminare i problemi e le richieste pull. Per ulteriori informazioni, vedere la guida per i collaboratori.
