I limiti e le quote proteggono l'infrastruttura Google da un processo automatizzato che utilizza in modo inappropriato l'API Email Audit. Le richieste eccessive di un'API potrebbero derivare da un errore di battitura innocuo o da un sistema inefficiente che effettua chiamate API inutili. Indipendentemente dalla causa, è necessario bloccare il traffico da una sorgente specifica quando raggiunge un determinato livello per l'integrità complessiva del sistema Google Workspace. I limiti contribuiscono a garantire che le azioni di uno sviluppatore non possano influire negativamente sulla community più ampia.
Nell'improbabile caso che la tua richiesta API non vada a buon fine, riceverai una risposta del codice di stato HTTP. Un codice di stato 403
contiene informazioni sugli errori relativi all'input errato, mentre un codice di stato HTTP 503
contiene informazioni sugli errori 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 in parallelo o utilizza più thread nell'applicazione Java o C#. Un esempio di richieste parallele è la richiesta di piccoli gruppi di email da parte di utenti diversi piuttosto che l'aggiunta o la rimozione contemporanea di molte email da un utente. Nel caso dei thread, prova a iniziare con 10 thread, uno per email utente. Tieni presente che il suggerimento dei thread ha compromessi e non è utile per tutte le situazioni API. Se il numero di richieste diventa troppo elevato, si verificano errori di quota. Un altro esempio di compromesso è la quota per l'API Email Audit per la frequenza di caricamento complessiva massima dei messaggi. La frequenza di caricamento è una richiesta API, al secondo, per utente, indipendentemente dal numero di thread che effettuano richieste di caricamento.
Per tutti gli errori basati sul tempo (massimo N elementi per N secondi per thread), soprattutto gli errori del codice di stato 503
, consigliamo al codice di rilevare l'eccezione e, utilizzando un algoritmo di backoff esponenziale, attendi un leggero ritardo prima di riprovare la chiamata non riuscita. Un esempio dell'API Email Audit per un thread è di attendere 5 secondi e riprovare 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 ridursi alla frequenza della richiesta fino a quando non viene soddisfatta una chiamata.
Ad esempio, aumenta il ritardo iniziale di 5 secondi a 10 secondi e riprova a eseguire la chiamata non riuscita. Stabilisci anche un limite per i nuovi tentativi. Ad esempio, riprova a eseguire la richiesta da 5 a 7 volte con tempi di ritardo diversi prima che l'applicazione restituisca un errore all'utente.
Nella tabella seguente sono elencati i limiti per l'API Email Audit:
Categorie limite API | Limiti |
---|---|
Creazione dei file della casella di posta criptati | La creazione dei file delle caselle di posta criptate potrebbe richiedere diversi giorni per garantire la preparazione del sistema, a seconda delle dimensioni. |
File della casella di posta criptati, errori con l'eliminazione | Quando si elimina una casella di posta criptata e si verificano errori, alla richiesta viene assegnato lo stato MARKED_DELETE . Questi riepiloghi e i file esportati vengono recuperati automaticamente per l'eliminazione da Google entro 24 ore (con possibili file rimanenti). Se lo stato di MARKED_DELETE viene restituito costantemente, prova una strategia di backoff esponenziale.
|
Nella tabella seguente sono elencate le quote per l'API Email Audit:
Categorie di quota API | Quote |
---|---|
Token di autenticazione ClientLogin | Valida per 24 ore. L'errore è 401 token expired .
|
Formati di data | Converti tutte le date nel formato UTC (Coordinated Universal TIme) prima di utilizzarle con l'API Email Audit. Per saperne di più, consulta la pagina Convertitore UTC. |
File della casella di posta criptati, EXPIRED riepiloghi ed file di esportazione
|
Google conserva i file della casella di posta criptati per 3 settimane. Trascorso questo periodo, vengono eliminati. È responsabilità dell'amministratore di dominio scaricare i file della casella di posta entro questo periodo di tempo. |
File delle caselle di posta criptati, formato | I file delle caselle di posta criptati sono in formato mbox. |
File delle caselle di posta criptate, richieste di creazione massime | Il numero massimo di richieste di creazione giornaliere di casella di posta è di 100 richieste totali da tutti gli amministratori del dominio. |
Stato dell'impaginazione, casella di posta criptata | Quando richiedi lo stato di tutte le richieste relative alla casella di posta, le risposte possono restituire grandi quantità di
dati. L'API Email Audit raggruppa questi dati in pagine contenenti ogni
pagina con un massimo di 100 voci e un URI in un tag link rel='next' che rimanda alla pagina successiva
dei risultati. Quando sviluppi la tua applicazione client, il codice deve gestire questi risultati aggiuntivi.
|
Monitoraggio email | Il numero massimo di richieste di monitoraggio email al giorno è 1500. Questo limite si applica al dominio e include tutte le richieste effettuate da qualsiasi amministratore durante il giorno. |
Chiave pubblica | L'API Email Audit supporta una sola chiave.
La chiave pubblica utilizza un software GNU Privacy Guard (GPG). È in formato PGP ed è una chiave di crittografia RSA con codifica ASCII. Prima di caricare la chiave pubblica, devi convertirla in una stringa codificata in base64. Il file della chiave pubblica deve essere letto con il set di caratteri US-ASCII, (IANA preferisce il nome del set di caratteri per ASCII). |
Ricerca in corso | I parametri searchQuery e includeDeleted si escludono a vicenda. Non è possibile eseguire una query di ricerca se il metodo di ricerca includeDeleted="true" è valido.
|