I limiti e le quote proteggono l'infrastruttura di Google da un processo automatizzato che utilizza l'API Reports in modo inappropriato. Le richieste eccessive da un'API potrebbero essere il risultato di un errore di battitura innocuo o di un sistema progettato in modo inefficiente che effettua chiamate API non necessarie. Indipendentemente dalla causa, il blocco del traffico da una fonte specifica una volta raggiunto un determinato livello è necessario per la salute generale del sistema Google Workspace. In questo modo, le azioni di uno sviluppatore non possono influire negativamente sulla community più ampia.
Nella remota eventualità che la richiesta API non vada a buon fine, riceverai una risposta con codice di stato HTTP. Un codice di stato 403 contiene informazioni sull'errore relativo a input errati, mentre un codice di stato HTTP 503 contiene informazioni sull'errore che indicano quali quote API sono state superate. Queste risposte consentono alla tua applicazione personalizzata di rilevare questi errori e intraprendere le azioni appropriate.
Se le richieste devono essere completate in un periodo di tempo fisso, inviale richieste in parallelo o utilizza più thread nella tua applicazione Java o C#. Un esempio di richieste parallele è la richiesta di piccoli batch di email da utenti diversi anziché l'aggiunta o la rimozione simultanea di molte email da un utente simultaneamente. Nel caso dei thread, prova a iniziare con 10 thread, un thread per email utente. Tieni presente che il consiglio sui thread presenta compromessi e non è utile per tutte le situazioni API. Se il numero di richieste diventa troppo elevato, si verificheranno errori di quota.
Per tutti gli errori basati sul tempo (massimo N elementi per N secondi per thread), in particolare gli errori con codice di stato 503, ti consigliamo di fare in modo che il codice rilevi l'eccezione e, utilizzando un algoritmo di backoff esponenziale, attenda un breve ritardo prima di riprovare la chiamata non riuscita. Un esempio di API Reports per un thread è attendere 5 secondi e riprovare la chiamata non riuscita. Se la richiesta va a buon fine, ripeti questo pattern per gli altri thread. Se la seconda richiesta non va a buon fine, l'applicazione deve ridurre la frequenza della richiesta finché una chiamata non va a buon fine. Ad esempio, aumenta il ritardo iniziale di 5 secondi a 10 secondi e riprova la chiamata non riuscita. Inoltre, decidi un limite di tentativi. Ad esempio, riprova una richiesta da 5 a 7 volte con tempi di ritardo diversi prima che l'applicazione restituisca un errore all'utente.
Limiti
| Categorie di limiti API | Limiti |
|---|---|
| Tassi di QPS e QPD dei report | L'API limita il numero di richieste per il tuo progetto Google Cloud.
Il valore predefinito impostato nella console Google Cloud è di 2400 query al minuto
per utente per progetto Google Cloud. Puoi aumentare questo limite dalla
pagina Quote API dell'SDK Admin
del tuo progetto Google Cloud.
Se questi limiti vengono superati, il server restituisce un codice di stato HTTP 503 codice. Utilizza l' algoritmo di backoff esponenziale quando riprovi le richieste. |
Limiti aggiuntivi per activities.list |
L'API activities.list ha un limite aggiuntivo di 250
query di filtro al minuto (15.000 query di filtro all'ora). Una query di filtro
è una richiesta API che contiene almeno uno dei seguenti parametri di query:
|
| Categorie di quote API | Quote |
| maxResults | Il numero di record elencati in ogni pagina della risposta di un'API va da 0 a 1000 record. Il valore predefinito è 1000 record. |
Altri tipi di limiti
| Altri tipi di limiti | Limitazioni e linee guida |
|---|---|
| Formato dati, predefinito | Il formato dati predefinito è JSON. L'API supporta anche il formato Atom. |
| Richieste non autorizzate | Google non consente richieste non autorizzate all'API. Una richiesta è considerata non autorizzata se non viene fornito alcun token di autorizzazione. Per ulteriori informazioni, consulta Autorizzare le richieste. |
| Messaggi di avviso |
|
Best practice per activities.list
Il
activities.list
è destinato a essere utilizzato per le indagini di controllo. Per prestazioni ottimali, la richiesta deve includere un intervallo di tempo utilizzando i
parametri startTime e endTime. Gli intervalli di tempo più ristretti
comportano tempi di risposta notevolmente più rapidi. Questo metodo non è
destinato al recupero di grandi volumi di audit log. Se esaurisci regolarmente la quota di richieste di filtro activities.list, valuta le seguenti opzioni:
- Configura l'esportazione dei log di Google Workspace in BigQuery e utilizza le potenti API di query di BigQuery per recuperare e analizzare i dati di cui hai bisogno senza vincoli di quota API.
- Utilizza richieste senza filtro con intervallo di tempo ed esegui il filtraggio lato client (ovvero la logica di filtraggio nella tua applicazione) anziché utilizzare le richieste di filtro. In questo modo puoi superare il limite di 250 query di filtro al minuto,ma sei comunque soggetto al limite di 2400 query al minuto per utente per progetto Google Cloud.