Limity i kwoty chronią infrastrukturę Google przed zautomatyzowanymi procesami, które wykorzystują interfejs Reports API w niewłaściwy sposób. Nadmierna liczba żądań z interfejsu API może być spowodowana nieszkodliwą literówką 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 niezbędne 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 niepowodzenia żądania interfejsu API otrzymasz kod stanu HTTP. Kod stanu 403 zawiera informacje o błędnych danych wejściowych, a kod stanu HTTP 503 zawiera informacje o tym, które limity interfejsu API zostały przekroczone. Te odpowiedzi umożliwiają aplikacji niestandardowej wykrywanie błędów i podejmowanie odpowiednich działań.
Jeśli Twoje żądania muszą zostać zrealizowane w określonym czasie, wysyłaj je równolegle lub używaj wielu wątków w aplikacji w języku Java lub C#. Przykładem żądań równoległych jest wysyłanie próśb o małe partie 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 na adres e-mail użytkownika. Pamiętaj, że zalecenie dotyczące wątków ma swoje wady i nie jest przydatne we wszystkich sytuacjach związanych z interfejsem API. Jeśli liczba żądań będzie zbyt wysoka, wystąpią błędy związane z limitem.
W przypadku wszystkich błędów związanych z czasem (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 za pomocą algorytmu wykładniczego wycofywania odczekiwał krótką chwilę przed ponowną próbą wykonania nieudanego wywołania. Przykładem użycia interfejsu Reports API w przypadku jednego wątku jest odczekanie 5 sekund i ponowienie nieudanego wywołania. Jeśli żądanie zostanie zrealizowane, powtórz ten wzorzec w przypadku pozostałych wątków. Jeśli druga prośba nie zostanie zrealizowana, aplikacja powinna zmniejszyć częstotliwość wysyłania próśb, dopóki nie zostanie zrealizowana. Możesz na przykład wydłużyć początkowe 5-sekundowe opóźnienie do 10 sekund i ponownie spróbować wykonać połączenie, które się nie powiodło. Określ też limit ponownych prób. Na przykład ponów żądanie 5–7 razy z różnymi czasami opóźnienia, zanim aplikacja zwróci użytkownikowi błąd.
Limity
| Kategorie limitów interfejsu API | Limity |
|---|---|
| Raportowanie liczby zapytań na sekundę i zapytań 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 limitów interfejsu Admin SDK API w projekcie Google Cloud.
Jeśli te limity zostaną przekroczone, serwer zwróci kod stanu HTTP 503. Podczas ponawiania żądań używaj algorytmu odczekiwania wykładniczego. |
Dodatkowe limity dla activities.list |
Interfejs activities.list API ma dodatkowy limit 250 zapytań z filtrem na minutę (15 000 zapytań z filtrem na godzinę).
Zapytanie filtra 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 wysyłane 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 metody activities.list
Metoda activities.list jest przeznaczona do kontroli.
Aby uzyskać najlepsze wyniki, żądanie powinno zawierać zakres czasu z użyciem parametrów startTime i endTime. Węższe zakresy czasu znacznie przyspieszają czas odpowiedzi.
Ta metoda nie jest przeznaczona do pobierania dużych ilości logów kontrolnych. Jeśli regularnie wyczerpujesz limit żądań filtra activities.list, rozważ te opcje:
- Skonfiguruj eksportowanie dzienników Google Workspace do BigQuery i używaj zaawansowanych interfejsów API zapytań BigQuery, aby pobierać i analizować potrzebne dane bez ograniczeń dotyczących limitu interfejsu API.
- Zamiast żądań z filtrem używaj żądań bez filtra z zakresem czasu i filtruj po stronie klienta (czyli stosuj logikę filtrowania w aplikacji). Pozwala to przekroczyć limit 250 zapytań o filtr na minutę,ale nadal obowiązuje limit 2400 zapytań na minutę na użytkownika w projekcie Google Cloud.