Limity i przydziały chronią infrastrukturę Google przed zautomatyzowanymi procesami, które używają interfejsu Reports API w nieodpowiedni sposób. Nadmierna liczba żądań z interfejsu API może być spowodowana nieszkodliwym błędem w pisowni lub nieefektywnie zaprojektowanym systemem, który wykonuje niepotrzebne wywołania interfejsu API. Niezależnie od przyczyny blokowanie ruchu z określonego źródła po osiągnięciu określonego poziomu jest konieczne dla ogólnej kondycji systemu Google Workspace. Dzięki temu działania jednego dewelopera nie mogą negatywnie wpłynąć na większą społeczność.
W mało prawdopodobnym przypadku nieudanego żądania do interfejsu API otrzymasz odpowiedź z kodem stanu HTTP. Kod stanu 403 zawiera informacje o błędach związanych z nieprawidłowymi danymi wejściowymi a kod stanu HTTP 503 zawiera informacje o błędach wskazujące, które limity interfejsu API zostały przekroczone. Te odpowiedzi umożliwiają aplikacji niestandardowej wykrywanie tych błędów i podejmowanie odpowiednich działań.
Jeśli żądania muszą zostać zrealizowane w określonym czasie, wysyłaj je równolegle lub używaj wielu wątków w aplikacji Java lub C#. Przykładem żądań równoległych jest wysyłanie żądań małych partii e-maili od różnych użytkowników zamiast dodawania lub usuwania wielu e-maili od jednego użytkownika jednocześnie. W przypadku wątków zacznij od 10 wątków, po jednym wątku na adres e-mail użytkownika. Pamiętaj, że zalecenie dotyczące wątków ma wady i nie jest przydatne we wszystkich sytuacjach związanych z interfejsem API. Jeśli liczba żądań będzie zbyt duża, wystąpią błędy związane z przekroczeniem limitu.
W przypadku wszystkich błędów opartych na czasie (maksymalnie N elementów przez N sekund na wątek), zwłaszcza błędów z kodem stanu 503, zalecamy, aby kod przechwytywał wyjątek i, używając algorytmu wykładniczego wycofywania , czekał przez krótki czas przed ponowieniem nieudanego wywołania. Przykładem interfejsu Reports API dla jednego wątku jest odczekanie 5 sekund i ponowienie nieudanego wywołania. Jeśli żądanie się powiedzie, powtórz ten wzorzec w przypadku pozostałych wątków. Jeśli drugie żądanie się nie powiedzie, aplikacja powinna zmniejszyć częstotliwość żądania, aż do momentu, gdy wywołanie się powiedzie. Na przykład zwiększ początkowe opóźnienie 5 sekund do 10 sekund i ponownie spróbuj wykonać nieudane wywołanie. Określ też limit ponownych prób. Na przykład przed zwróceniem błędu użytkownikowi aplikacja może ponowić żądanie 5–7 razy z różnymi czasami opóźnienia.
Limity
| Kategorie limitów interfejsu API | Limity |
|---|---|
| Liczba zapytań na sekundę i na dzień | Interfejs API ogranicza liczbę żądań w projekcie Google Cloud.
Wartość domyślna ustawiona w konsoli Google Cloud to 2400 zapytań na minutę
na użytkownika na projekt Google Cloud. Ten limit możesz zwiększyć na
stronie Limity interfejsu Admin SDK API
w projekcie Google Cloud.
Jeśli te limity zostaną przekroczone, serwer zwróci kod stanu HTTP 503 code. Podczas ponawiania żądań używaj algorytmu wykładniczego wycofywania. |
Dodatkowe limity dotyczące activities.list |
Interfejs activities.list API ma dodatkowy limit 250
zapytań z filtrem na minutę (15 000 zapytań z filtrem na godzinę). Zapytanie z filtrem
to żądanie do interfejsu API, które zawiera co najmniej 1 z tych parametrów zapytania:
|
| Kategorie limitów interfejsu API | Limity |
| maxResults | Liczba rekordów wymienionych na każdej stronie odpowiedzi interfejsu API wynosi od 0 do 1000. Wartość domyślna to 1000 rekordów. |
Inne rodzaje limitów
| Inne rodzaje limitów | Ograniczenia i wytyczne |
|---|---|
| Format danych, domyślny | Domyślny format danych to JSON. Interfejs API obsługuje też format Atom. |
| Nieautoryzowane żądania | Google nie zezwala na nieautoryzowane żądania do interfejsu API. Żądanie jest uznawane za nieautoryzowane, jeśli nie podano tokena autoryzacji. Więcej informacji znajdziesz w artykule Autoryzowanie żądań. |
| Komunikaty ostrzegawcze |
|
Sprawdzone metody dotyczące activities.list
Oczekuje się, że metoda
activities.list
będzie używana do prowadzenia dochodzeń. Aby uzyskać najlepszą
wydajność, żądanie powinno zawierać zakres czasu określony za pomocą
startTime i endTime parametrów. Węższe zakresy czasu
znacznie przyspieszają czas odpowiedzi. Ta metoda nie jest
przeznaczona do pobierania dzienników kontrolnych w dużych ilościach. Jeśli regularnie
wyczerpujesz limit żądań z filtrem w activities.list, rozważ te
opcje:
- Skonfiguruj Google workspace logs export to BigQuery i używaj zaawansowanych interfejsów API zapytań BigQuery, aby pobierać i analizować potrzebne dane bez ograniczeń limitu interfejsu API constraints.
- Zamiast żądań z filtrem używaj żądań bez filtra z zakresem czasu i filtruj po stronie klienta (czyli wykonuj logikę filtrowania w aplikacji), zamiast używać żądań z filtrem. Dzięki temu możesz przekroczyć limit 250 zapytań z filtrem na minutę ale nadal obowiązuje Cię limit 2400 zapytań na minutę na użytkownika na projekt Google Cloud.