העלאת תמונות באמצעות Play Games Services Publishing API

Play Games Services Publishing API מאפשר להעלות תמונה של משחק משאב.

האפשרויות להעלאה

Play Games Services Publishing API מאפשר להעלות סוגים מסוימים של נתונים בינאריים או מדיה. המאפיינים הספציפיים של הנתונים שאפשר להעלות מצוינים בדף העזר עבור כל שיטה שתומכת בהעלאות מדיה:

  • גודל קובץ מקסימלי להעלאה: כמות הנתונים המקסימלית שאפשר לאחסן עם בשיטה הזו.

  • סוגי MIME נתמכים של מדיה: סוגי הנתונים הבינאריים שאפשר לאחסן באמצעות בשיטה הזו.

אפשר לשלוח בקשות העלאה בכל אחת מהדרכים הבאות. ציון השיטה שבהם אתם משתמשים עם פרמטר הבקשה של UploadType.

  • העלאה פשוטה: uploadType=media. להעברה מהירה של לקבצים קטנים יותר, לדוגמה, בגודל של עד 5MB.

  • העלאה מרובת חלקים: uploadType=multipart. למהיר העברה של קבצים ומטא-נתונים קטנים יותר, מעביר את הקובץ יחד עם המטא-נתונים שמתארת את התהליך, בבקשה אחת.

  • העלאה שניתן להמשיך: uploadType=resumable. אמין העברה, במיוחד עם קבצים גדולים. בשיטה הזאת משתמשים בקשה להתחלת סשן, שיכולה לכלול מטא-נתונים. זהו מתאימה לרוב האפליקציות, כי היא עובדת גם קבצים בעלות של בקשת HTTP אחת נוספת לכל העלאה.

כשמעלים מדיה, צריך להשתמש ב-URI מיוחד. למעשה, שיטות שתומכות להעלאות מדיה יש שתי נקודות קצה ב-URI:

  • ה-URI /upload, למדיה. הפורמט של נקודת הקצה להעלאה הוא ב-URI של משאב סטנדרטי עם קידומת ' /upload'. שימוש ב-URI הזה כשמעבירים את נתוני המדיה עצמם.

    דוגמה: POST /upload/games/v1configuration/images/resourceId/imageType/imageType

  • ה-URI הסטנדרטי של המשאב, למטא-נתונים. אם המשאב מכיל שדות נתונים, השדות האלה משמשים לאחסון מטא-נתונים שמתארים את חדש. אפשר להשתמש ב-URI הזה כשיוצרים או מעדכנים ערכי מטא-נתונים.

    דוגמה: POST /games/v1configuration/images/resourceId/imageType/imageType

העלאה פשוטה

השיטה הישירה ביותר להעלאת קובץ היא בקשה להעלאה. כדאי להשתמש באפשרות הזו אם מתקיים אחד מהתנאים הבאים:

  • הקובץ קטן מספיק כדי להעלות אותו שוב בשלמותו אם החיבור נכשל.

  • אין מטא-נתונים לשליחה. אולי זה נכון אם אתם מתכוונים לשלוח מטא-נתונים למשאב הזה בבקשה נפרדת, או אם אין תמיכה במטא-נתונים, או זמינים. כדי להשתמש בהעלאה פשוטה, שולחים בקשת POST או PUT ה-URI של /upload ומוסיפים את פרמטר השאילתה uploadType=media. לדוגמה:

POST https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=media

כותרות ה-HTTP שבהן צריך להשתמש כששולחים בקשת העלאה פשוטה כוללות:

  • Content-Type מגדירים את אחד מסוגי הנתונים המקובלים להעלאה של מדיה, צוין ב-Advertising API הפניה.

  • Content-Length מגדירים את מספר הבייטים שמעלים. לא נדרש אם משתמשים קידוד העברה במקטעים.

דוגמה: העלאה פשוטה

הדוגמה הבאה ממחישה שימוש בבקשת העלאה פשוטה בשביל Play Games Services Publishing API.

POST /upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=media HTTP/1.1
Host: www.googleapis.com
Content-Type: image/png
Content-Length: number_of_bytes_in_file
Authorization: Bearer your_auth_token

PNG data

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

HTTP/1.1 200
Content-Type: application/json

{
  "kind": "gamesConfiguration#imageConfiguration",
  "url": string,
  "resourceId": string,
  "imageType": string
}

העלאה מרובת חלקים

אם יש מטא-נתונים שאתם רוצים לשלוח יחד עם הנתונים להעלאה, יכול לשלוח בקשת multipart/related אחת. כדאי להשתמש באפשרות הזאת אם הנתונים שאתם שולחים קטן מספיק כדי להעלות שוב את כולו בשלמותו, החיבור נכשל.

כדי להשתמש בהעלאה מרובת חלקים, צריך לשלוח בקשת POST או PUT לשיטה ה-URI של /upload ומוסיפים את פרמטר השאילתה uploadType=multipart. לדוגמה:

POST https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=multipart

כותרות ה-HTTP ברמה העליונה שבהן צריך להשתמש כששולחים בקשה להעלאה מרובת חלקים כוללים:

Content-Type- צריך להגדיר את הטווח בתור 'מרוב חלקים'/'קשור' ולכלול את מחרוזת הגבולות שבה אתם משתמשים כדי לזהות את חלקי הבקשה.

Content-Length- מוגדר למספר הכולל של הבייטים בגוף הבקשה. חלק המדיה בבקשה חייב להיות קטן מגודל הקובץ המקסימלי שצוין לשיטה הזו.

גוף הבקשה מעוצב כסוג תוכן מרובה חלקים/תוכן קשור RFC2387 וגם מכיל בדיוק שני חלקים. החלקים מזוהים באמצעות מחרוזת גבול, וגם אחרי מחרוזת הגבול האחרונה מופיעים שני מקפים.

לכל חלק של הבקשה מרובת החלקים נדרשת כותרת Content-Type נוספת:

  • חלק של מטא-נתונים: חייב להיות ראשון, והסוג Content-Type חייב להתאים לאחד מהפורמטים הקבילים של מטא-נתונים.

  • חלק מדיה: חייב להיות שני, והסוג Content-Type חייב להתאים לאחד מסוגי ה-MIME של המדיה הקבילים בשיטה.

צפייה פרסום חומר עזר של ה-API לכל אחת מהשיטות המותרות לפרסום סוגי MIME של מדיה ומגבלות גודל לקבצים שהועלו.

דוגמה: העלאה מרובת חלקים

בדוגמה הבאה מוצגת בקשת העלאה מרובת חלקים עבור Play Games Services Publishing API.

POST /upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=multipart HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer your_auth_token
Content-Type: multipart/related; boundary=foo_bar_baz
Content-Length: number_of_bytes_in_entire_request_body

--foo_bar_baz
Content-Type: application/json; charset=UTF-8

{
  "kind": "gamesConfiguration#imageConfiguration",
  "url": string,
  "resourceId": string,
  "imageType": string
}

--foo_bar_baz
Content-Type: image/png

PNG data
--foo_bar_baz--

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

HTTP/1.1 200
Content-Type: application/json

{
  "kind": "gamesConfiguration#imageConfiguration",
  "url": string,
  "resourceId": string,
  "imageType": string
}

העלאה שניתן להמשיך

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

השלבים לשימוש בהעלאה שניתן להמשיך כוללים:

  1. התחלת סשן שניתן להמשיך. שולחים בקשה ראשונית ל-URI להעלאה שכוללת את המטא-נתונים, אם יש כאלה.

  2. שומרים את ה-URI של הסשן שניתן להמשיך. שמירת ה-URI של הסשן שהוחזר בתשובה של הבקשה הראשונית; נשתמש בהם בשאר הבקשות סשן. מעלים את הקובץ.

  3. שולחים את קובץ המדיה אל ה-URI של הסשן שניתן להמשיך.

בנוסף, אפליקציות שמשתמשות בהעלאה שניתן להמשיך צריכים לכלול קוד כדי להמשיך העלאה שהופסקה. אם ההעלאה הופסקה, כדאי לבדוק כמה נתונים התקבלו בהצלחה ולהמשיך את ההעלאה החל מנקודה זו.

התחלת סשן שניתן להמשיך

כדי להתחיל העלאה שניתן להמשיך, שולחים בקשת POST או PUT ל-URI של השיטה /upload ומוסיפים את פרמטר השאילתה uploadType=resumable. לדוגמה:

POST https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable

בבקשה הראשונית הזו, הגוף ריק או מכיל את המטא-נתונים בלבד. תעבירו את התוכן של הקובץ בפועל שתרצו להעלות בבקשות הבאות.

בבקשה הראשונית משתמשים בכותרות ה-HTTP הבאות:

  • X-Upload-Content-Type צריך להגדיר את סוג ה-MIME של המדיה של נתוני ההעלאה שיועברו בבקשות הבאות.

  • X-Upload-Content-Length מוגדר למספר הבייטים של נתוני ההעלאה שיהיו יועברו בבקשות הבאות. אם האורך לא ידוע את הבקשה הזו, אפשר להשמיט את הכותרת.

  • אם מספקים מטא-נתונים: Content-Type. מוגדר בהתאם לנתוני המטא-נתונים מהסוג הזה.

  • Content-Length צריך להגדיר את מספר הבייטים שצוין בגוף הטקסט לבקשה הראשונית. לא נדרש אם משתמשים קידוד העברה במקטעים.

מידע נוסף על Publishing API עבור הרשימה של סוגי ה-MIME המותרים של המדיה ומגבלות הגודל לקבצים שהועלו, עבור כל אחת מהשיטות.

דוגמה: בקשת התחלת סשן שניתן להמשיך

בדוגמה הבאה ניתן לראות איך להתחיל סשן שניתן להמשיך עבור Play Games Services Publishing API.

POST /upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer your_auth_token
Content-Length: 38
Content-Type: application/json; charset=UTF-8
X-Upload-Content-Type: image/png
X-Upload-Content-Length: 2000000

{
  "kind": "gamesConfiguration#imageConfiguration",
  "url": string,
  "resourceId": string,
  "imageType": string
}

בקטע הבא מוסבר איך לטפל בתשובה.

שמירת ה-URI של הסשן שניתן להמשיך

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

דוגמה: תגובה להתחלת סשן שניתן להמשיך

זו התגובה לבקשה בשלב 1:

HTTP/1.1 200 OK
Location: https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable&upload_id=xa298sd_sdlkj2
Content-Length: 0

ערך הכותרת Location, כפי שמוצג בתשובה לדוגמה שלמעלה, הוא ה-URI של הסשן שבו תשתמשו כנקודת הקצה של HTTP להעלאת הקובץ בפועל או להריץ שאילתות לגבי סטטוס ההעלאה.

מעתיקים ושומרים את ה-URI של הסשן כדי להשתמש בו לבקשות הבאות.

העלאת הקובץ

כדי להעלות את הקובץ, צריך לשלוח בקשת PUT ל-URI של ההעלאה שקיבלתם השלב הקודם. הפורמט של בקשת ההעלאה הוא:

PUT session_uri

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

דוגמה: בקשה להעלאת קובץ שניתן להמשיך

זאת בקשה שניתן להמשיך כדי להעלות את כל קובץ PNG בגודל 2,000,000 בייטים, לצורך הדוגמה הנוכחית.

PUT https://www.googleapis.com/upload/games/v1configuration/images/resourceId/imageType/imageType?uploadType=resumable&upload_id=xa298sd_sdlkj2 HTTP/1.1
Content-Length: 2000000
Content-Type: image/png

bytes 0-1999999

אם הבקשה מצליחה, השרת ישיב עם HTTP 201 Created, מטא-נתונים שמשויכים למשאב הזה. אם הבקשה הראשונית הסשן שניתן להמשיך היה PUT, כדי לעדכן משאב קיים, הפעולה הסתיימה התשובה תהיה 200 OK, יחד עם כל המטא-נתונים שמשויכים לזה משאב.

אם בקשת ההעלאה הופסקה או אם מקבלים תגובת HTTP 503 Service Unavailable או כל תגובת 5xx אחרת מהשרת, יש לפעול לפי ההליך המתואר ב המשך העלאה שהופסקה.

העלאת הקובץ במקטעי נתונים

העלאות שניתן להמשיך מאפשרות לחלק קובץ למקטעי נתונים ולשלוח סדרה של בקשות להעלות כל מקטע ברצף. זו לא הגישה המועדפת מכיוון שיש עלויות ביצועים שקשורות לבקשות הנוספות, בדרך כלל אין בו צורך. עם זאת, ייתכן שתצטרכו להשתמש במקטע נתונים כדי לצמצם כמות הנתונים שהועברו בבקשה יחידה. זה שימושי כשיש הוא מגבלת זמן קבועה לבקשות נפרדות, כמו גם בסוגים מסוימים של בקשות של Google App Engine. הוא גם מאפשר לבצע פעולות כמו העלאת קובץ מדדי התקדמות בדפדפנים מדור קודם שאין בהם תמיכה בהתקדמות בהעלאה. כברירת מחדל.

אם אתם מעלים את הנתונים במקטעי נתונים, גם הכותרת Content-Range (טווח תוכן) נדרש, יחד עם הכותרת Content-Length (אורך תוכן) שנדרשת להעלאות מלאות של קבצים:

  • Content-Length צריך להגדיר את גודל המקטע או יכול להיות קטן ממנו, כמו במקרה של הבקשה האחרונה.

  • Content-Range: הגדרה זו מאפשרת להציג אילו בייטים בקובץ אתם מעלים. עבור לדוגמה, Content-Range: bytes 0-524287/2000000 מראה שאתם מספקים את 524,288 הבייטים הראשונים בקובץ בגודל 2,000,000 בייטים.

דוגמה: בקשה להעלאת קובץ מקטעי נתונים שניתן להמשיך

בקשה ששולחת את 524,288 הבייטים הראשונים עשויה להיראות כך:

PUT {session_uri} HTTP/1.1
Host: www.googleapis.com
Content-Length: 524288
Content-Type: image/png
Content-Range: bytes 0-524287/2000000

bytes 0-524288

אם הבקשה מצליחה, השרת ישיב עם 308 Resume Incomplete, יחד עם עם כותרת 'Range' שמזהה את המספר הכולל של הבייטים מאוחסנים עד עכשיו:

HTTP/1.1 308 Resume Incomplete
Content-Length: 0
Range: bytes=0-524287

כדי לקבוע מאיפה להתחיל, צריך להשתמש בערך העליון שמוחזר בכותרת Range את המקטע הבא. ממשיכים אל PUT כל מקטע בקובץ עד שהקובץ כולו הועלה.

אם בקשת PUT של מקטע כלשהו הופסקה או אם מקבלים תגובת HTTP 503 Service Unavailable או כל תגובת 5xx אחרת מהשרת, יש לפעול לפי התהליך שמתואר ב המשך העלאה שהופסקה, אבל במקום להעלות את שאר הקובץ, פשוט המשיכו להעלות מקטעי נתונים מאותו רגע.

הערות חשובות:

  • יש להקפיד להשתמש בכותרת Range בתשובה כדי לקבוע מאיפה להתחיל את המקטע הבא; לא מניחים שהשרת קיבל את כל הבייטים שנשלחו הבקשה הקודמת.

  • לכל מזהה URI של העלאה יש משך חיים מוגבל, ובסופו של דבר התוקף שלו פג (תוך יום או לכן, אם לא נעשה בו שימוש). לכן מומלץ להתחיל העלאה שניתן להמשיך בתור מיד כשמקבלים את ה-URI של ההעלאה, וממשיכים תוך זמן קצר בהעלאה שהופסקה אחרי ההפרעה.

  • אם שולחים בקשה עם מזהה סשן העלאה שתוקפו פג, השרת מחזיר קוד סטטוס 404 Not Found. כשמתרחשת בהעלאה שגיאה שבעקבותיה אי אפשר לשחזר אותו סשן, השרת יחזיר קוד סטטוס 410 Gone. במקרים כאלה, צריך התחלה של העלאה חדשה שניתן להמשיך, קבלת URI חדש להעלאה והתחלת ההעלאה מ- בנקודת הקצה החדשה.

כשהעלאת הקובץ כולה מסתיימת, השרת מגיב עם HTTP 201 Created יחד עם המטא-נתונים המשויכים למשאב הזה. אם הבקשה שעדכנת ישות קיימת במקום ליצור ישות חדשה, ה-HTTP קוד התגובה להעלאה שהושלמה הוא 200 OK.

המשך העלאה שהופסקה

אם בקשת העלאה הופסקה לפני קבלת תשובה או אם מקבלים תגובת HTTP 503 Service Unavailable מהשרת, צריך להמשיך את ההעלאה שהופסקה. כדי להמשיך העלאה שהופסקה, מבצעים את הפעולות הבאות:

  1. סטטוס הבקשה. שליחת שאילתה לגבי הסטטוס הנוכחי של ההעלאה על ידי הנפקת בקשת PUT ריקה ל-URI של ההעלאה. עבור הבקשה הזו, כותרות ה-HTTP צריכות לכלול כותרת Content-Range שמציינת שהמיקום הנוכחי הקובץ לא ידוע. לדוגמה, יש להגדיר את Content-Range לערך */2000000 אם אורך הקובץ הכולל הוא 2,000,000. אם אתם לא יודעים מה הגודל המלא של הקובץ, מגדירים אותו טווח התוכן של */*.

  2. קבלת מספר הבייטים שמעלים. מעבדים את התשובה משאילתת הסטטוס. השרת משתמש בכותרת Range בתגובה שלו כדי לציין אילו בייטים יש לו. שהתקבלו עד עכשיו. לדוגמה, כותרת Range של 0-299999 מציינת ש- התקבלו 300,000 הבייטים הראשונים של הקובץ.

  3. מעלים את הנתונים שנותרו. לבסוף, עכשיו אתם יודעים לאן להמשיך שולחים את הנתונים הנותרים או את המקטע הנוכחי. לתשומת ליבכם, צריך לטפל באזהרה את שאר הנתונים כמקטע נפרד בכל מקרה, לכן צריך לשלוח את Content-Range כשממשיכים את ההעלאה.

דוגמה: המשך העלאה שהופסקה

  1. מבקשים את סטטוס ההעלאה. הבקשה הבאה משתמשת בטווח התוכן כדי לציין שהמיקום הנוכחי בקובץ בגודל 2,000,000 בייטים לא ידועה.

    PUT {session_uri} HTTP/1.1
Content-Length: 0
Content-Range: bytes */2000000

  2. מחלצים את מספר הבייטים שהועלו עד עכשיו מהתגובה. תגובת השרת משתמשת בכותרת Range כדי לציין שהוא קיבל את 43 הבייטים הראשונים של הקובץ עד כה. צריך להשתמש בערך העליון של הכותרת 'טווח' כדי לקבוע מאיפה להתחיל את ההעלאה מחדש.

HTTP/1.1 308 Resume Incomplete
Content-Length: 0
Range: 0-42
  1. ממשיכים בהעלאה מהנקודה שבה היא נעצרה. הבקשה הבאה ממשיך את ההעלאה על ידי שליחת הבייטים הנותרים בקובץ, החל מהבייטים 43.
PUT {session_uri} HTTP/1.1
Content-Length: 1999957
Content-Range: bytes 43-1999999/2000000

bytes 43-1999999

שיטות מומלצות

כשמעלים מדיה, כדאי לשים לב לכמה שיטות מומלצות שקשורות לטיפול בשגיאות.

  • להמשיך או לנסות שוב העלאות שנכשלו עקב הפרעות בחיבור או שגיאות 5xx, כולל:

    • 500 Internal Server Error
    • 502 Bad Gateway
    • 503 Service Unavailable
    • 504 Gateway Timeout

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

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

  • כדי לטפל בשגיאות 404 Not Found ו-410 Gone, כשמבצעים העלאות שניתן להמשיך, צריך להתחיל את ההעלאה כולה מההתחלה.

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

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

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

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

  1. שולחים בקשה ל-API.
  2. מקבלים את התשובה HTTP 503, שמצביעה על כך שצריך לנסות שוב את הבקשה.
  3. יש להמתין שנייה אחת + הכמות האקראית_number_milliseconds ולנסות שוב את הבקשה.
  4. מקבלים את התשובה HTTP 503, שמצביעה על כך שצריך לנסות שוב את הבקשה.
  5. צריך להמתין 2 שניות +Android_number_milliseconds, ולנסות שוב את הבקשה.
  6. מקבלים את התשובה HTTP 503, שמצביעה על כך שצריך לנסות שוב את הבקשה.
  7. צריך להמתין 4 שניות +Android_number_milliseconds, ולנסות שוב את הבקשה.
  8. מקבלים HTTP 503 response, שמציין שצריך לנסות שוב את הבקשה.
  9. צריך להמתין 8 שניות +GCLID_number_milliseconds, ולנסות שוב את הבקשה.
  10. מקבלים HTTP 503 response, שמציין שצריך לנסות שוב את הבקשה.
  11. צריך להמתין 16 שניות +Android_number_milliseconds, ולנסות שוב את הבקשה.
  12. הפסקת ההפעלה. תיעוד או דיווח על שגיאה.

ברשימה שלמעלה, האקראי_number_milliseconds הוא מספר אקראי של אלפיות השנייה קטן מ-1000 או שווה ל-1000. זה הכרחי, מכיוון שמוסיפים ערך אקראי קטן עיכוב עוזר לפזר את העומס באופן שווה יותר ולמנוע את האפשרות לחתום את השרת. יש להגדיר מחדש את הערך שלAndroid_number_milliseconds לאחר כל המתנה.

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

מדריכים בנושא ספריות לקוח ל-API