Limiti e quote proteggono l'infrastruttura di Google da un processo automatizzato che utilizza l'API Reports in modo inappropriato. Un numero eccessivo di richieste da un'API potrebbe essere dovuto a un errore di battitura innocuo o a un sistema progettato in modo inefficiente che effettua chiamate API inutili. Indipendentemente dalla causa, bloccare il traffico proveniente 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.
Nell'improbabile 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 all'input errato, 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 l'azione appropriata.
Se le tue richieste devono essere completate in un periodo di tempo fisso, inviale in parallelo o utilizza più thread nella tua applicazione Java o C#. Un esempio di richieste parallele è la richiesta di piccoli batch di email di utenti diversi anziché l'aggiunta o la rimozione simultanea di molte email di un solo utente. Nel caso dei thread, prova a iniziare con 10 thread, uno per ogni email utente. Tieni presente che il suggerimento relativo ai thread presenta dei compromessi e non è utile per tutte le situazioni dell'API. Se il numero di richieste diventa troppo elevato, si verificano errori di quota.
Per tutti gli errori basati sul tempo (massimo N elementi per N secondi per thread), in particolare gli errori del 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 consiste nell'attendere 5 secondi e riprovare a effettuare la chiamata non riuscita. Se la richiesta ha esito positivo, ripeti questo pattern per gli altri thread. Se la seconda richiesta non va a buon fine, l'applicazione deve ridurre la frequenza delle richieste finché una chiamata non va a buon fine. Ad esempio, aumenta il ritardo iniziale di 5 secondi a 10 secondi e riprova a effettuare la chiamata non riuscita. Inoltre, decidi un limite di tentativi. Ad esempio, riprova a effettuare una richiesta 5-7 volte con tempi di ritardo diversi prima che l'applicazione restituisca un errore all'utente.
Limiti
| Categorie di limiti API | Limiti |
|---|---|
| Report sui tassi di QPS e QPD | L'API limita il numero di richieste per il tuo progetto Google Cloud.
Il valore predefinito impostato nella console Google Cloud è 2400 query al minuto per utente per progetto Google Cloud.
Puoi aumentare questo limite dalla pagina Quote API SDK Admin del tuo progetto Google Cloud.
Se questi limiti vengono superati, il server restituisce un codice di stato HTTP 503. Utilizza l'algoritmo di backoff esponenziale quando riprovi a inviare 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. Il valore predefinito è 1000 record. |
Altri tipi di limiti
| Altri tipi di limiti | Limitazioni e linee guida |
|---|---|
| Formato dei dati, predefinito | Il formato dei dati predefinito è JSON. L'API supporta anche il formato Atom. |
| Richieste non autorizzate | Google non consente richieste non autorizzate all'API. Una richiesta viene considerata non autorizzata se non viene fornito alcun token di autorizzazione. Per maggiori informazioni, consulta Autorizzazione delle richieste. |
| Messaggi di avviso |
|
Best practice per activities.list
Il metodo activities.list deve essere utilizzato per le indagini di controllo.
Per ottenere le migliori prestazioni, la richiesta deve includere un intervallo di tempo utilizzando i parametri startTime e endTime. Intervalli di tempo più ristretti comportano tempi di risposta molto più rapidi.
Questo metodo non è concepito per il 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 filtri con intervallo di tempo ed esegui il filtraggio lato client (ovvero la logica di filtraggio nella tua applicazione) anziché utilizzare richieste con filtri. In questo modo puoi superare il limite di 250 query di filtro al minuto,ma rimani comunque soggetto al limite di 2400 query al minuto per utente per progetto Google Cloud.