Na tej stronie znajdziesz listę błędów, które możesz otrzymać od interfejsu User Deletion API, oraz informacje o tym, jak rozwiązywać problemy z błędami 500 i jak wdrożyć odstępowanie od skoku kwadratowego.
Standardowe odpowiedzi na błędy
Jeśli żądanie interfejsu User Deletion API zakończy się powodzeniem, interfejs API zwróci kod stanu 200.
Jeśli wystąpi błąd żądania, interfejs API zwraca kod stanu HTTP, stan i przyczynę w odpowiedzi na podstawie typu błędu. Dodatkowo treść odpowiedzi zawiera 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 | Przyczyna | Opis | Zalecane działanie |
|---|---|---|---|
| 400 | invalidParameter |
Wskazuje, że parametr żądania ma nieprawidłową wartość. Pola locationType i location w odpowiedzi na błąd podają informacje o tym, która wartość była nieprawidłowa. |
Nie próbuj ponownie, jeśli problem nie został rozwiązany. 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 nieprawidłowa kombinacja wymiarów lub danych. | Nie próbuj ponownie, jeśli problem nie został rozwiązany. Aby zapytanie do interfejsu API działało, musisz wprowadzić w nim zmiany. |
| 401 | invalidCredentials |
Wskazuje, że token uwierzytelniania jest nieprawidłowy lub stracił ważność. | Nie próbuj ponownie, jeśli problem nie został rozwiązany. Musisz uzyskać nowy token uwierzytelniający. |
| 403 | insufficientPermissions |
Wskazuje, że użytkownik nie ma wystarczających uprawnień do zasobu określonego w zapytaniu. | Nie ponawiaj próby bez rozwiązania problemu. Musisz mieć wystarczające uprawnienia do wykonania operacji na określonym obiekcie. |
| 403 | dailyLimitExceeded |
Wskazuje, że użytkownik przekroczył dzienny limit (na projekt lub widok (profil)). | Nie próbuj ponownie, jeśli problem nie został rozwiązany. Dzienny limit został wykorzystany. Zobacz Limity i limity interfejsów API. |
| 403 | userRateLimitExceeded |
Wskazuje, że przekroczono limit liczba zapytań na 100 sekund na użytkownika. Domyślna wartość ustawiona w Konsoli interfejsów API Google to 100 zapytań na 100 sekund na użytkownika. Możesz zwiększyć ten limit w Konsoli interfejsów API Google do maksymalnie 1000. | Ponownie spróbuj, używając wzrastającego czasu do ponownej próby. Musisz zmniejszyć szybkość wysyłania żądań. |
| 403 | rateLimitExceeded |
Wskazuje, że przekroczono limity częstotliwości zapytań na 100 sekund w przypadku projektu. | Ponownie spróbuj, używając wzrastającego czasu do ponownej próby. Musisz zmniejszyć szybkość wysyłania żądań. |
| 403 | quotaExceeded |
Wskazuje, że osiągnięto limit 10 jednoczesnych żądań na widok (profil) w interfejsie Core Reporting API. | Ponownie spróbuj, używając wzrastającego czasu do ponowienia. Musisz poczekać na zakończenie co najmniej 1 wciąż trwającego żądania dotyczącego tego widoku (profilu). |
| 500 | internalServerError |
Wystąpił nieoczekiwany błąd wewnętrzny serwera. | Nie powtarzaj tego zapytania więcej niż raz. |
| 503 | backendError |
Serwer zwrócił błąd. | Nie powtarzaj tego zapytania więcej niż raz. |
Obsługa odpowiedzi 500 lub 503
Podczas dużego obciążenia lub w przypadku większych, bardziej złożonych żądań może wystąpić błąd 500 lub 503. W przypadku większych żądań rozważ wysłanie prośby o dane dla krótszego okresu. Warto też wdrożyć wzrastający czas do ponowienia. Częstotliwość występowania tych błędów może zależeć od widoku (profilu) i ilości danych raportowania powiązanych z tym widokiem. Zapytanie, które powoduje błąd 500 lub 503 w jednym widoku (profilu), nie spowoduje koniecznie błędu w przypadku tego samego zapytania w innym widoku (profilu).
Wdróż wykładniczy czas do ponowienia
Wzrost opóźnienia to proces, w którym klient okresowo próbuje ponownie wysłać nieudane żądanie, zwiększając czas opóźnienia. Jest to standardowa strategia obsługi błędów w przypadku aplikacji sieciowych. Interfejs User Deletion API został zaprojektowany z założeniem, że klienci, którzy zdecydują się na ponowne wysłanie nieudanych żądań, zrobią to za pomocą algorytmu Exponential back-off. Oprócz tego, że jest „wymagane”, stosowanie wygładzania wykładniczego zwiększa efektywność wykorzystania przepustowości, zmniejsza liczbę żądań wymaganych do uzyskania odpowiedzi oraz maksymalizuje przepustowość żądań w środowiskach o wielu klientach.
Aby zastosować funkcję wzrastającego czasu do ponownej próby:
- Wyślij żądanie do interfejsu API.
- Odbieranie komunikatu o błędzie zawierającego kod błędu z możliwością ponownego próby.
- Zaczekaj 1 s +
random_number_millisecondss. - Ponownie wysłać prośbę.
- Odbieranie komunikatu o błędzie zawierającego kod błędu z możliwością ponownego próby.
- Zaczekaj 2 s +
random_number_millisecondss. - Ponownie wysłać prośbę.
- Odbieranie komunikatu o błędzie zawierającego kod błędu z możliwością ponownego próby.
- Poczekaj 4 s +
random_number_millisecondss. - Ponownie wysłać prośbę.
- Odbieranie komunikatu o błędzie zawierającego kod błędu z możliwością ponownej próby.
- Odczekaj 8 s +
random_number_millisecondss. - Ponownie wysłać prośbę.
- Odbieranie komunikatu o błędzie zawierającego kod błędu z możliwością ponownego próby.
- Zaczekaj 16 s +
random_number_millisecondss. - Ponownie wysłać prośbę.
- Jeśli błąd nadal występuje, zatrzymaj się i zgłoś go.
W poprzednim fragmencie kodu random_number_milliseconds to losowa liczba milisekund mniejsza lub równa 1000. Jest to konieczne, aby uniknąć pewnych błędów blokowania w niektórych implementacjach współbieżnych. random_number_millisecondsmusi zostać zdefiniowany ponownie po każdym oczekiwaniu.
Algorytm jest ustawiony tak, aby zakończyć działanie, gdy n = 5. Ten limit jest stosowany tylko w celu zapobiegania nieograniczonemu powtarzaniu prób przez klientów i powoduje opóźnienie około 32 sekund przed uznaniem żądania za „nieodwracalny błąd”.
Poniższy kod Pythona jest implementacją poprzedniego procesu naprawiania błędów występujących w metodzie o nazwie 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."