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 è una tecnica usata dalle API cloud per limitare il numero di richieste che possono essere effettuate in un periodo di tempo specifico. La limitazione garantisce che l'API rimanga disponibile e rispondente a tutti gli utenti. Impedisce inoltre a qualsiasi singolo utente di usare troppe risorse.
È possibile sperimentare la limitazione in diversi modi. Un modo comune consiste nell'usare i codici di stato HTTP. Ad esempio, quando si supera il numero consentito di richieste, l'API potrebbe restituire un 429 Too Many Requests codice di stato. Questa risposta indica che hai inviato troppe richieste in un periodo di tempo specifico e che dovresti rallentare. Non tutte le API usano 429: GitHub può anche rispondere con 403 e Anthropic usa 529 quando l'intera API è sovraccarica.
Oltre ai codici di stato, alcune API forniscono altre informazioni nelle intestazioni o nel corpo della risposta. Ad esempio, potrebbero usare l'intestazione Retry-After per indicare il tempo di attesa prima di effettuare un'altra richiesta.
È necessario essere consapevoli dei limiti di limitazione delle API usate e sapere come gestire la limitazione delle richieste nelle app, in modo che rimangano reattive e affidabili quando l'API è sotto carico elevato.
Come il throttling influisce sulla tua app
Quando un'API limita l'app e l'app non la gestisce, l'app si arresta in modo anomalo, mostra un errore generico, riprova così velocemente che continua a essere soggetta a limitazione o perde i dati senza avvisare. Raramente viene visualizzato nulla di tutto questo durante lo sviluppo, perché l'API è veloce, si è l'unico utente e i dati di test sono di piccole dimensioni.
Come testare che l'app gestisca la limitazione
| Avvicinarsi | Cosa trovi | Quello che ti manca |
|---|---|---|
| Attendere l'ambiente di produzione | throttling reale | Tutto, fino a quando un utente non ci fa clic |
| Simula l'API nei test oppure consenti all'agente di coding di scrivere il mock | Se il ramo di ripetizione dei tentativi viene eseguito | I codici di stato, le Retry-After intestazioni e i corpi di errore reali dell'API, e i criteri di ripetizione dei tentativi dell'SDK. L'app richiede anche un interruttore di sola prova per raggiungere il mock. |
| Chiama l'API reale fino a quando non ti applica il throttling | Comportamento reale | Non è possibile attivare il throttling su richiesta e si usa la quota reale |
| Intercettare il traffico reale dell'app e simulare la limitazione | URL reali, l'SDK reale e i criteri di ripetizione dei tentativi e se l'app attende fino a quando Retry-After indica |
Il codice isolato. Mantieni gli unit test per quello. |
Provalo nella tua app
Dev Proxy restituisce risposte di limitazione per le API scelte, mentre l'app continua a chiamare gli URL reali. Indica anche quando l'app chiama di nuovo l'API prima che scada il tempo Retry-After.
Scaricare il set di impostazioni per l'API che l'app chiama e avviare Dev Proxy con esso:
devproxy config get microsoft-graph-rate-limiting
devproxy --config-file "~dataFolder/configs/microsoft-graph-rate-limiting/.devproxy/devproxyrc.json"
| API | Preset |
|---|---|
Microsoft Graph (OneDrive e SharePoint: /drive, /shares, /sites) |
microsoft-graph-rate-limiting |
| GitHub | github-rate-limiting |
| OpenAI | openai-throttling |
| Anthropic | anthropic-throttling |
Per qualsiasi altra API, vedere Testare che l'applicazione gestisca correttamente la limitazione. Per installare Dev Proxy, vedere Configurare Dev Proxy.
Passaggi successivi
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.
