Limits und Kontingente schützen die Google-Infrastruktur vor einem automatisierten Prozess, der die Email Audit API auf unangemessene Weise verwendet. Übermäßige Anfragen von einer API können von einem harmlosen Tippfehler oder von einem ineffizienten System stammen, das unnötige API-Aufrufe ausführt. Unabhängig vom Grund ist es für den Gesamtzustand des Google Workspace-Systems erforderlich, Traffic von einer bestimmten Quelle zu blockieren, wenn er ein bestimmtes Level erreicht. Limits sollen verhindern, dass die Aktionen eines Entwicklers die gesamte Community beeinträchtigen können.
In dem unwahrscheinlichen Fall, dass Ihre API-Anfrage fehlschlägt, erhalten Sie eine HTTP-Statuscodeantwort. Der Statuscode 403 enthält Fehlerinformationen über eine falsche Eingabe. Der HTTP-Statuscode 503 enthält Fehlerinformationen, die angeben, welche API-Kontingente überschritten wurden. Anhand dieser Antworten kann Ihre benutzerdefinierte Anwendung diese Fehler erkennen und entsprechende Maßnahmen ergreifen.
Wenn die Anfragen innerhalb eines bestimmten Zeitraums abgeschlossen sein müssen, senden Sie sie parallel oder verwenden Sie mehrere Threads in Ihrer Java- oder C#-Anwendung. Ein Beispiel für parallele Anfragen ist die Anforderung kleiner Mengen von E-Mails von verschiedenen Nutzern, anstatt viele E-Mails eines Nutzers gleichzeitig hinzuzufügen oder zu entfernen. Bei Threads empfiehlt es sich, mit 10 Threads zu beginnen, ein Thread pro E-Mail-Adresse des Nutzers. Beachten Sie, dass die Thread-Empfehlung Kompromisse hat und nicht für alle API-Situationen nützlich ist. Wenn die Anzahl der Anfragen zu hoch wird, treten Kontingentfehler auf. Ein weiteres Kompromiss ist das Kontingent für die Email Audit API für die maximale Uploadrate für Nachrichten insgesamt. Die Uploadrate ist eine API-Anfrage pro Sekunde und Nutzer, unabhängig davon, wie viele Threads Uploadanfragen senden.
Bei zeitbasierten Fehlern (maximal N Elemente für N Sekunden pro Thread), insbesondere dem Statuscode 503, sollte der Code die Ausnahme abfangen. Warten Sie dann mit einem exponentiellen Backoff-Algorithmus, bis der fehlgeschlagene Aufruf wiederholt wird. Ein Beispiel für eine Email Audit API für einen Thread ist es, fünf Sekunden zu warten und den fehlgeschlagenen Aufruf zu wiederholen. Wenn die Anfrage erfolgreich ist, wiederholen Sie dieses Muster für die anderen Threads. Wenn die zweite Anfrage nicht erfolgreich ist, sollte die Anwendung die Häufigkeit der Anfrage reduzieren, bis der Aufruf erfolgreich war.
Erhöhen Sie beispielsweise die anfängliche Verzögerung von fünf Sekunden auf zehn Sekunden und versuchen Sie den fehlgeschlagenen Aufruf noch einmal. Legen Sie außerdem ein Wiederholungslimit fest. Wiederholen Sie beispielsweise eine Anfrage fünf bis sieben Mal mit unterschiedlichen Verspätungen, bevor Ihre Anwendung einen Fehler an den Nutzer zurückgibt.
In der folgenden Tabelle sind die Limits für die Email Audit API aufgeführt:
| API-Grenzwertkategorien | Limits |
|---|---|
| Verschlüsselte Postfachdateien, Erstellung | Die Erstellung verschlüsselter Postfachdateien kann je nach Größe einige Tage dauern. |
| Verschlüsselte Postfachdateien, Fehler beim Löschen | Wenn beim Löschen eines verschlüsselten Postfachs Fehler auftreten, erhält die Anfrage den Status MARKED_DELETE. Diese Zusammenfassungen und Exportdateien werden von Google innerhalb von 24 Stunden automatisch gelöscht. Unter Umständen bleiben noch Dateien übrig. Wenn der Status MARKED_DELETE immer zurückgegeben wird, versuchen Sie es mit einer exponentiellen Backoff-Strategie.
|
In der folgenden Tabelle sind die Kontingente für die Email Audit API aufgeführt:
| API-Kontingentkategorien | Kontingente |
|---|---|
| ClientLogin-Authentifizierungstokens | 24 Stunden lang gültig. Der Fehler lautet 401 token expired.
|
| Datumsformate | Konvertieren Sie alle Datumsangaben in das Format des koordinierten Universal Untime (UTC), bevor Sie sie mit der Email Audit API verwenden. Weitere Informationen finden Sie unter UTC-Converter. |
Verschlüsselte Postfachdateien, EXPIRED Zusammenfassungen und Exportdateien
|
Google speichert die verschlüsselten Postfachdateien drei Wochen lang. Danach werden sie gelöscht. Der Domainadministrator muss diese Postfachdateien innerhalb dieses Zeitraums herunterladen. |
| Verschlüsselte Postfachdateien, Format | Verschlüsselte Postfachdateien haben das Format MBOX. |
| Verschlüsselte Postfachdateien, maximale Anzahl von Erstellungsanfragen | Die maximale Anzahl von Anfragen zum Erstellen eines Postfachexports pro Tag beträgt insgesamt 100 Anfragen von allen Administratoren in der Domain. |
| Status der verschlüsselten Postfachdatei, Paginierung | Wenn Sie den Status aller Postfachanfragen anfordern, können Antworten große Datenmengen zurückgeben. Die Email Audit API fasst diese Daten in Seiten zusammen, wobei jede Seite maximal 100 Einträge und einen URI in einem link rel='next'-Tag enthält, der auf die nächste Ergebnisseite verweist. Wenn Sie Ihre Clientanwendung entwickeln, muss Ihr Code diese zusätzlichen Ergebnisse verwalten.
|
| E-Mail-Überwachung | Pro Tag sind maximal 1.500 Anfragen zulässig. Dieses Limit gilt für die Domain und umfasst alle Anfragen, die von einem Administrator während des Tages gestellt wurden. |
| Öffentlicher Schlüssel | Die Email Audit API unterstützt nur einen Schlüssel.
Der öffentliche Schlüssel verwendet die GNU Privacy Guard-Software (GPG). Sie hat das PGP-Format und ist ein ASCII-codierter RSA-Verschlüsselungsschlüssel. Vor dem Hochladen des öffentlichen Schlüssels müssen Sie ihn zuerst in einen base64-codierten String konvertieren. Die öffentliche Schlüsseldatei sollte mit dem Zeichensatz US-ASCII (IANA bevorzugter Zeichensatzname für ASCII) gelesen werden. |
| Suchen | Die Parameter searchQuery und includeDeleted schließen sich gegenseitig aus. Eine Suchanfrage ist nicht möglich, wenn includeDeleted="true".
|