Standardowe odpowiedzi na błędy
Jeśli żądanie API do zarządzania zostanie zrealizowane, interfejs API zwróci kod stanu 200. Jeśli w żądaniu wystąpi błąd, interfejs API zwróci w odpowiedzi kod stanu, stan i przyczynę na podstawie typu błędu.
Treść odpowiedzi zawiera również szczegółowy opis przyczyny błędu. Oto przykładowa odpowiedź na błąd:
{
"error": {
"errors": [
{
"domain": "global",
"reason": "invalidParameter",
"message": "Invalid value '-1' for max-results. Value must be within the range: [1, 1000]",
"locationType": "parameter",
"location": "max-results"
}
],
"code": 400,
"message": "Invalid value '-1' for max-results. Value must be within the range: [1, 1000]"
}
}
Tabela błędów
| Kod | Uzasadnienie | Opis | Zalecane działanie |
|---|---|---|---|
| 400 | invalidParameter |
Wskazuje, że parametr żądania ma nieprawidłową wartość. Pola locationType i location w odpowiedzi na błąd zawierają informacje o tym, która wartość jest nieprawidłowa. |
Spróbuj ponownie bez rozwiązania problemu. Musisz podać prawidłową wartość parametru określonego w odpowiedzi na błąd. |
| 400 | badRequest |
Wskazuje, że zapytanie jest nieprawidłowe. np. brak identyfikatora nadrzędnego lub połączenie żądanych wymiarów lub danych było nieprawidłowe. | Spróbuj ponownie bez rozwiązania problemu. Musisz zmienić ustawienia interfejsu API, by działały. |
| 401 | invalidCredentials |
Wskazuje, że token uwierzytelniania jest nieprawidłowy lub stracił ważność. | Spróbuj ponownie bez rozwiązania problemu. Musisz uzyskać nowy token uwierzytelniania. |
| 403 | insufficientPermissions |
Wskazuje, że użytkownik nie ma wystarczających uprawnień do podmiotu określonego w zapytaniu. | Spróbuj ponownie bez rozwiązania problemu. Aby wykonać operację na określonym elemencie, musisz mieć odpowiednie uprawnienia. |
| 403 | dailyLimitExceeded |
Wskazuje, że użytkownik przekroczył limit dzienny (na projekt lub na widok (profil)). | Spróbuj ponownie bez rozwiązania problemu. Dzienny limit został wykorzystany. Zobacz Limity API. |
| 403 | userRateLimitExceeded |
Wskazuje, że przekroczono limit Zapytania na 100 sekund na użytkownika. Wartość domyślna ustawiona w Konsoli interfejsów API Google to 100 zapytań na 100 sekund na użytkownika. Limit ten w konsoli Google API możesz zwiększyć do maksymalnie 1000. | Spróbuj ponownie za pomocą generowania wykładniczego odwrotu. Musisz zmniejszyć szybkość wysyłania żądań. |
| 403 | rateLimitExceeded |
Wskazuje, że przekroczono limity liczby żądań na 100 sekund w projekcie. | Spróbuj ponownie za pomocą generowania wykładniczego odwrotu. Musisz zmniejszyć szybkość wysyłania żądań. |
| 403 | quotaExceeded |
Wskazuje, że w interfejsie Core Reporting API zostało osiągniętych 10 żądań równoczesnych na widok danych. | Spróbuj ponownie, korzystając z generowania wykładniczego ponowienia. W tym widoku (profilu) należy zaczekać na co najmniej jedną trwającą prośbę. |
| 500 | internalServerError |
Wystąpił nieoczekiwany wewnętrzny błąd serwera. | Nie ponawiaj tego zapytania więcej niż raz. |
| 503 | backendError |
Serwer zwrócił błąd. | Nie ponawiaj tego zapytania więcej niż raz. |
Obsługa odpowiedzi 500 lub 503
Błąd 500 lub 503 może skutkować dużym obciążeniem lub bardziej złożonymi żądaniami. W przypadku większych żądań poproś o dane przez krótszy okres. Rozważ też wdrożenie wykładniczego ponowienia.
Częstotliwość tych błędów może zależeć od widoku danych (profilu) oraz ilości danych raportowania powiązanych z tym widokiem. Zapytanie powodujące błąd 500 lub 503 w przypadku jednego widoku (profilu) nie musi powodować błędu dla tego samego zapytania w innym widoku (profilu).
Wdrożenie wykładniczego ponowienia
Wycofywanie wykładnicze to proces, w którym klient okresowo ponawia próbę zrealizowania nieudanego żądania przez dłuższy czas. Jest to standardowa strategia obsługi błędów dla aplikacji sieciowych. Interfejs API zarządzania został opracowany tak, aby klienty, które zdecydują się na ponowienie nieudanych żądań, powinny to zrobić za pomocą wykładniczego ponawiania. Poza tym, że wykładnicze jest wymagane, aby zwiększyć wykorzystanie przepustowości, zmniejszyć liczbę żądań niezbędnych do uzyskania odpowiedzi oraz zmaksymalizować przepustowość w środowiskach równoczesnych.
Proces implementacji prostego pogłębiania wykładniczego wygląda tak.
- Wyślij żądanie do interfejsu API
- Otrzymuj odpowiedź o błędzie z kodem błędu dotyczącym ponawiania próby
- Poczekaj 1 s +
random_number_millisecondss - Ponów próbę
- Otrzymuj odpowiedź o błędzie z kodem błędu dotyczącym ponawiania próby
- Poczekaj 2 s i
random_number_millisecondssekund - Ponów próbę
- Otrzymuj odpowiedź o błędzie z kodem błędu dotyczącym ponawiania próby
- Zaczekaj 4 s i
random_number_millisecondss - Ponów próbę
- Otrzymuj odpowiedź o błędzie z kodem błędu dotyczącym ponawiania próby
- Zaczekaj 8 s +
random_number_millisecondss - Ponów próbę
- Otrzymuj odpowiedź o błędzie z kodem błędu dotyczącym ponawiania próby
- Zaczekaj 16 s i
random_number_millisecondss - Ponów próbę
- Jeśli błąd nadal występuje, zatrzymaj go i zapisz.
W powyższym procesie random_number_milliseconds jest losową liczbą milisekund mniejszą lub równą 1000. Jest to konieczne, aby uniknąć niektórych błędów blokady w niektórych równoczesnych implementacjach.
Po każdym czekaniu wartość random_number_milliseconds musi zostać zdefiniowana ponownie.
Uwaga: oczekiwanie jest zawsze (2 ^ n) + random_number_milliseconds, gdzie n to monotonnie rosnąca liczba całkowita, którą definiuje się początkowo jako 0. Liczba n zwiększa się o 1 przy każdej iteracji (przy każdym żądaniu).
Algorytm jest zakończony, gdy n ma wartość 5. Ten limit obowiązuje tylko po to, aby uniemożliwić klientom nieskończone ponawianie próby i całkowicie opóźnione jest około 32 sekundy, zanim żądanie zostanie uznane za nieodwracalny błąd.
Wymieniony poniżej kod Pythona służy do implementacji powyższego procesu do odzyskiwania danych z błędów występujących w metodzie makeRequest.
import random
import time
from apiclient.errors import HttpError
def makeRequestWithExponentialBackoff(analytics):
"""Wrapper to request Google Analytics data with exponential backoff.
The makeRequest method accepts the analytics service object, makes API
requests and returns the response. If any error occurs, the makeRequest
method is retried using exponential backoff.
Args:
analytics: The analytics service object
Returns:
The API response from the makeRequest method.
"""
for n in range(0, 5):
try:
return makeRequest(analytics)
except HttpError, error:
if error.resp.reason in ['userRateLimitExceeded', 'quotaExceeded',
'internalServerError', 'backendError']:
time.sleep((2 ** n) + random.random())
else:
break
print "There has been an error, the request never succeeded."