תגובות לשגיאות

בדף הזה מפורטות השגיאות שעשויות להתקבל מ-User Deletion API, ומוסבר איך לטפל בשגיאות מסוג 500 ולהטמיע השהיה מעריכית לפני ניסיון חוזר.

תגובות סטנדרטיות לשגיאות

אם בקשת API למחיקת משתמשים תתבצע בהצלחה, ה-API יחזיר קוד סטטוס 200. אם מתרחשת שגיאה בבקשה, ה-API מחזיר בתגובה קוד סטטוס, סטטוס וסיבה של HTTP בהתאם לסוג השגיאה. בנוסף, גוף התשובה מכיל תיאור מפורט של מה שגרם לשגיאה. דוגמה לתשובת שגיאה:

 { "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]" } }

הערה: התיאור עשוי להשתנות בכל שלב, לכן האפליקציות לא צריכות להסתמך על טקסט התיאור בפועל.

טבלת שגיאות

קוד	סיבה	תיאור	מה מומלץ לעשות?
400	invalidParameter	מציין שלפרמטר של הבקשה יש ערך לא חוקי. השדות locationType ו-location בתשובה לשגיאה מספקים מידע לגבי הערך שהיה לא תקין.	אין לנסות שוב בלי לפתור את הבעיה. צריך לספק ערך תקין לפרמטר שצוין בתגובת השגיאה.
400	badRequest	מציין שהשאילתה לא חוקית. לדוגמה, מזהה ההורה חסר או שהשילוב של המאפיינים או המדדים המבוקשים לא חוקי.	אין לנסות שוב בלי לפתור את הבעיה. כדי שהשאילתה ל-API תפעל, צריך לבצע בה שינויים.
401	invalidCredentials	מציין שאסימון האימות לא תקין או שפג תוקפו.	אין לנסות שוב ללא תיקון הבעיה. צריך לקבל אסימון אימות חדש.
403	insufficientPermissions	מציין שלמשתמש אין מספיק הרשאות לגבי הישות שצוינה בשאילתה.	אין לנסות שוב בלי לפתור את הבעיה. צריך לקבל הרשאות מספיקות כדי לבצע את הפעולה על הישות שצוינה.
403	dailyLimitExceeded	מציין שהמשתמש חרג מהמכסה היומית (לכל פרויקט או לכל תצוגה (פרופיל)).	אין לנסות שוב בלי לפתור את הבעיה. ניצלת את המכסה היומית שלך. מגבלות ומכסות של API
403	userRateLimitExceeded	הסטטוס הזה מציין חריגה מהמגבלה של שאילתות לכל 100 שניות לכל משתמש. ערך ברירת המחדל שמוגדר ב-Google API Console הוא 100 שאילתות לכל 100 שניות לכל משתמש. אפשר להגדיל את המגבלה הזו ב-מסוף Google API ל-1,000 לכל היותר.	אפשר לנסות שוב באמצעות השהיה מעריכית לפני ניסיון חוזר (exponential backoff). עליך להאט את קצב שליחת הבקשות.
403	rateLimitExceeded	הסטטוס הזה מציין חריגה ממגבלות הקצב של שאילתות לכל 100 שניות בפרויקט.	אפשר לנסות שוב באמצעות השהיה מעריכית לפני ניסיון חוזר (exponential backoff). עליך להאט את קצב שליחת הבקשות.
403	quotaExceeded	מציין שהגעתם ל-10 בקשות בו-זמנית לכל צפייה (פרופיל) ב-Core Reporting API.	אפשר לנסות שוב באמצעות השהיה מעריכית לפני ניסיון חוזר (exponential backoff). עליך להמתין לפחות בקשה אחת פעילה כדי שהתצוגה המפורטת הזו (הפרופיל) תושלם.
500	internalServerError	אירעה שגיאה פנימית בלתי צפויה בשרת.	אין לנסות שוב את השאילתה הזו יותר מפעם אחת.
503	backendError	השרת החזיר שגיאה.	אין לנסות שוב את השאילתה הזו יותר מפעם אחת.

טיפול ב-500 או 503 תשובות

שגיאה מסוג 500 או 503 עשויה להתרחש במהלך עומס כבד או לבקשות גדולות ומורכבות יותר. בבקשות גדולות יותר, כדאי לבקש נתונים לתקופת זמן קצרה יותר. כדאי גם להטמיע השהיה מעריכית לפני ניסיון חוזר (exponential backoff). תדירות השגיאות האלה עשויה להיות תלויה בתצוגה (בפרופיל) ובכמות נתוני הדיווח המשויכים לתצוגה הזו. שאילתה שגורמת לשגיאה מסוג 500 או 503 בתצוגה (בפרופיל) אחת לא בהכרח תגרום לשגיאה באותה שאילתה עם תצוגה (פרופיל) אחרת.

הטמעת השהיה מעריכית לפני ניסיון חוזר (exponential backoff)

השהיה מעריכית לפני ניסיון חוזר (exponential backoff) היא התהליך שבו לקוח מנסה שוב ושוב לשלוח בקשה שנכשלה לאורך זמן שגדל. זוהי אסטרטגיה סטנדרטית לטיפול בשגיאות באפליקציות רשת. User Deletion API תוכנן מתוך הנחה שלקוחות שבוחרים לנסות שוב בקשות שנכשלו עושים זאת באמצעות השהיה מעריכית לפני ניסיון חוזר (exponential backoff). בנוסף לכך שהיא 'חובה', השימוש בהשהיה מעריכית לפני ניסיון חוזר מגדיל את היעילות של השימוש ברוחב הפס, מפחית את מספר הבקשות הנדרשות כדי לקבל תשובה מוצלחת ומגדיל את תפוקת הבקשות בסביבות בו-זמניות.

כך מטמיעים השהיה מעריכית לפני ניסיון חוזר:

1. שולחים בקשה ל-API.
2. מתקבלת תגובת שגיאה עם קוד שגיאה שניתן לנסות שוב.
3. צריך להמתין שנייה אחת + random_number_milliseconds שניות.
4. שולחים את הבקשה שוב.
5. מתקבלת תגובת שגיאה עם קוד שגיאה שניתן לנסות שוב.
6. ממתינים 2 שניות + random_number_milliseconds שניות.
7. שולחים את הבקשה שוב.
8. מתקבלת תגובת שגיאה עם קוד שגיאה שניתן לנסות שוב.
9. ממתינים 4 שניות + random_number_milliseconds שניות.
10. שולחים את הבקשה שוב.
11. מתקבלת תגובת שגיאה עם קוד שגיאה שניתן לנסות שוב.
12. ממתינים 8 שניות + random_number_milliseconds שניות.
13. שולחים את הבקשה שוב.
14. מתקבלת תגובת שגיאה עם קוד שגיאה שניתן לנסות שוב.
15. ממתינים 16 שניות + random_number_milliseconds שניות.
16. ניסיון חוזר לשלוח את הבקשה.
17. אם עדיין מופיעה הודעת שגיאה, מפסיקים ורושמים את השגיאה.

בתהליך הקודם, random_number_milliseconds הוא מספר אקראי של אלפיות שנייה שקטן מ-1,000 או שווה לו. הפעולה הזו נחוצה כדי למנוע שגיאות מסוימות של נעילת קבצים בהטמעות בו-זמניות מסוימות. צריך להגדיר מחדש את random_number_milliseconds אחרי כל המתנה.

הערה: זמן ההמתנה הוא תמיד (2 ^ n) + random_number_milliseconds, כאשר n הוא מספר שלם שגדל באופן מונוטוני ומוגדר בהתחלה כ-0. n גדל ב-1 בכל חזרה (כל בקשה).

האלגוריתם מוגדר להסתיים כאשר n הוא 5. המכסה הזו קיימת רק כדי למנוע מהלקוחות לנסות שוב ושוב, והיא גורמת להשהיה כוללת של כ-32 שניות לפני שהבקשה נחשבת "לשגיאה שלא ניתן לשחזור".

קוד Python הבא הוא הטמעה של התהליך הקודם לשחזור משגיאות שמתרחשות בשיטה שנקראת 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."