Durch Limits und Kontingente wird die Google-Infrastruktur vor automatisierten Prozessen geschützt, die die Email Audit API auf unangemessene Weise verwenden. Eine übermäßige Anzahl von Anfragen von einer API kann durch einen harmlosen Tippfehler oder ein ineffizient gestaltetes System verursacht werden, das unnötige API-Aufrufe ausführt. Unabhängig von der Ursache ist es für den Gesamtzustand des Google Workspace-Systems wichtig, den Traffic von einer bestimmten Quelle zu blockieren, sobald er einen bestimmten Wert erreicht. Limits sollen verhindern, dass die Aktionen eines Entwicklers sich negativ auf die gesamte Community auswirken.
Im unwahrscheinlichen Fall, dass Ihre API-Anfrage fehlschlägt, erhalten Sie eine Antwort mit einem HTTP-Statuscode. Ein Statuscode von 403 enthält Fehlerinformationen zu falscher Eingabe und ein HTTP-Statuscode von 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 Ihre Anfragen innerhalb eines bestimmten Zeitraums abgeschlossen werden müssen, senden Sie sie parallel oder verwenden Sie mehrere Threads in Ihrer Java- oder C#-Anwendung. Ein Beispiel für parallele Anfragen ist das Anfordern kleiner Batches von E‑Mails von verschiedenen Nutzern, anstatt viele E‑Mails gleichzeitig von einem Nutzer hinzuzufügen oder zu entfernen. Bei Threads sollten Sie mit 10 Threads beginnen, einem Thread pro E-Mail-Adresse des Nutzers. Die Empfehlung für Threads hat Nachteile und ist nicht für alle API-Situationen nützlich. Wenn die Anzahl der Anfragen zu hoch wird, treten Kontingentfehler auf. Ein weiteres Beispiel für einen Kompromiss ist das Kontingent für die Email Audit API für die maximale Gesamtrate für den Nachrichten-Upload. Die Uploadrate beträgt eine API-Anfrage pro Sekunde und Nutzer, unabhängig davon, wie viele Threads Uploadanfragen senden.
Bei allen zeitbasierten Fehlern (maximal N Elemente für N Sekunden pro Thread), insbesondere bei Fehlern mit dem Statuscode 503, empfehlen wir, dass Ihr Code die Ausnahme abfängt und mit einem exponentiellen Backoff-Algorithmus eine kurze Zeit wartet, bevor er den fehlgeschlagenen Aufruf noch einmal versucht. Ein Beispiel für die Email Audit API für einen Thread: Warten Sie 5 Sekunden und wiederholen Sie den fehlgeschlagenen Aufruf. Wenn die Anfrage erfolgreich ist, wiederholen Sie diesen Vorgang für die anderen Threads. Wenn die zweite Anfrage nicht erfolgreich ist, sollte die Häufigkeit der Anfragen in Ihrer Anwendung reduziert werden, bis ein Aufruf erfolgreich ist. Erhöhen Sie beispielsweise die anfängliche Verzögerung von 5 Sekunden auf 10 Sekunden und versuchen Sie es noch einmal. Legen Sie außerdem ein Limit für Wiederholungsversuche fest. Wiederholen Sie eine Anfrage beispielsweise fünf- bis siebenmal mit unterschiedlichen Verzögerungszeiten, 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-Limitkategorien | Limits |
|---|---|
| Erstellung verschlüsselter Postfachdateien |
Die Erstellung verschlüsselter Postfachdateien kann je nach Größe bis zu mehrere Tage dauern. |
| Verschlüsselte Mailboxdateien, Fehler beim Löschen |
Wenn beim Löschen eines verschlüsselten Postfachs Fehler auftreten, erhält die Anfrage den Status |
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: |
| Datumsformate |
Konvertieren Sie alle Datumsangaben in das Format der koordinierten Weltzeit (UTC), bevor Sie sie mit der Email Audit API verwenden. Weitere Informationen finden Sie unter UTC-Konverter. |
|
Verschlüsselte Postfachdateien, |
Google speichert die verschlüsselten Postfachdateien drei Wochen lang. Danach werden sie gelöscht. Der Domainadministrator ist dafür verantwortlich, diese Postfachdateien innerhalb dieses Zeitraums herunterzuladen. |
| Verschlüsselte Postfachdateien, Format |
Verschlüsselte Postfachdateien haben das mbox-Format. |
| Verschlüsselte Postfachdateien, maximale Anzahl von Erstellungsanfragen |
Die maximale Anzahl von Anfragen zum Erstellen von Postfachexporten 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 unterteilt diese Daten in Seiten mit jeweils maximal 100 Einträgen und einem URI in einem |
| E-Mail-Überwachung |
Die maximale Anzahl von E‑Mail-Überwachungsanfragen pro Tag beträgt 1.500. Dieses Limit gilt für die Domain und umfasst alle Anfragen, die von einem Administrator während des Tages gestellt werden. |
| Öffentlicher Schlüssel |
Die Email Audit API unterstützt nur einen Schlüssel. Für den öffentlichen Schlüssel wird die Software GNU Privacy Guard (GPG) verwendet. Er hat das PGP-Format und ist ein ASCII-codierter RSA-Verschlüsselungsschlüssel. Bevor Sie den öffentlichen Schlüssel hochladen, müssen Sie ihn in einen Base64-codierten String umwandeln. Die Datei mit dem öffentlichen Schlüssel sollte mit dem Zeichensatz US-ASCII gelesen werden (IANA bevorzugt diesen Zeichensatznamen für ASCII). |
| Recherche |
Die Parameter |