דף זה תורגם על ידי Cloud Translation API.

המדיה שהעלית

התכונה של העלאת מדיה מאפשרת ל-Campaign Manager 360 API לאחסן נתונים בענן ולהפוך אותם לזמינים לשרת. סוגי הנתונים שהלקוח עשוי לרצות להעלות כוללים תמונות, סרטונים, קובצי PDF, קובצי ZIP או כל סוג אחר של נתונים.

הדוגמאות שבמסמך הזה מראות את השימוש בהעלאת מדיה ל-Famention API הפיקטיבי. עם זאת, אותם מושגים חלים על Campaign Manager 360 API.

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

Campaign Manager 360 API מאפשר להעלות סוגים מסוימים של מדיה או נתונים בינאריים. המאפיינים הספציפיים של הנתונים שאפשר להעלות מפורטים בדף העזר לכל שיטה שתומכת בהעלאות מדיה:

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

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

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

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

ה-URI של ‎/upload, עבור המדיה. הפורמט של נקודת הקצה להעלאה הוא מזהה ה-URI הסטנדרטי של המשאב עם הקידומת ‎/upload. השתמשו ב-URI הזה כאשר ומעביר את נתוני המדיה עצמם.
לדוגמה: POST /upload/farm/v1/animals
מזהה ה-URI הסטנדרטי של המשאב, למטא-נתונים. אם המשאב מכיל שדות נתונים, השדות האלה משמשים לאחסון מטא-נתונים שמתארים את הקובץ שהועלו. אפשר להשתמש ב-URI הזה כשיוצרים או מעדכנים ערכי מטא-נתונים.
דוגמה: POST /farm/v1/animals

העלאה פשוטה

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

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

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

POST https://www.googleapis.com/upload/farm/v1/animals?uploadType=media

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

Content-Type. מגדירים את השדה לאחד מסוגי הנתונים המותרים של מדיה להעלאה בשיטה, כפי שמפורט בחומר העזרה של ה-API.
Content-Length מגדירים את מספר הבייטים שמעלים. זה לא נדרש אם משתמשים בקידוד העברה במקטעים.

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

הדוגמה הבאה מציגה שימוש בבקשת העלאה פשוטה בשביל ה-API הבדיוני של החווה.

POST /upload/farm/v1/animals?uploadType=media HTTP/1.1
Host: www.googleapis.com
Content-Type: image/jpeg
Content-Length: number_of_bytes_in_file
Authorization: Bearer your_auth_token

JPEG data

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

HTTP/1.1 200
Content-Type: application/json

{
  "name": "Llama"
}

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

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

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

POST https://www.googleapis.com/upload/farm/v1/animals?uploadType=multipart

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

Content-Type. מגדירים את הערך ל-multipart/related וכוללים את מחרוזת הגבול שבה משתמשים כדי לזהות את החלקים של הבקשה.
Content-Length. מוגדר למספר הבייטים הכולל בגוף הבקשה. החלק של המדיה בבקשה חייב להיות קטן מגודל הקובץ המקסימלי שצוין לשיטה הזו.

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

צריך להוסיף כותרת Content-Type לכל חלק בבקשה מרובת החלקים:

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

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

הערה: כדי ליצור או לעדכן את החלק של המטא-נתונים בלבד, מבלי להעלות את הנתונים המשויכים, צריך פשוט לשלוח בקשת POST או PUT לנקודת הקצה הרגילה של המשאב: https://www.googleapis.com/farm/v1/animals

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

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

POST /upload/farm/v1/animals?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

{
  "name": "Llama"
}

--foo_bar_baz
Content-Type: image/jpeg

JPEG data
--foo_bar_baz--

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

HTTP/1.1 200
Content-Type: application/json

{
  "name": "Llama"
}

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

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

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

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

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

הערה: התוקף של ה-URI של ההעלאה פג לאחר שבוע.

שלב 1: מתחילים סשן שניתן להמשיך

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

POST https://www.googleapis.com/upload/farm/v1/animals?uploadType=resumable

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

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

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

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

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

בדוגמה הבאה מוצג איך מתחילים סשן שניתן להמשיך אותו ב-Farm API הבדיוני.

POST /upload/farm/v1/animals?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/jpeg
X-Upload-Content-Length: 2000000

{
  "name": "Llama"
}

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

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

שלב 2: שומרים את ה-URI של הסשן שניתן להמשיך

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

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

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

HTTP/1.1 200 OK
Location: https://www.googleapis.com/upload/farm/v1/animals?uploadType=resumable&upload_id=xa298sd_sdlkj2
Content-Length: 0

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

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

שלב 3: העלאת הקובץ

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

PUT session_uri

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

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

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

PUT https://www.googleapis.com/upload/farm/v1/animals?uploadType=resumable&upload_id=xa298sd_sdlkj2 HTTP/1.1
Content-Length: 2000000
Content-Type: image/jpeg

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 הבייטים הראשונים (256 x 1024 x 2) בקובץ של 2,000,000 בייטים.

הגבלת גודל המקטע: כל המקטעים חייבים להיות בגודל של כפולה של 256KB (256 x 1,024 בייטים), מלבד המקטע האחרון שמסמן את סיום ההעלאה. אם אתם משתמשים במקטע נתונים, חשוב להקפיד שגודל המקטע יהיה גדול ככל האפשר כדי שההעלאה תהיה יעילה.

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

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

PUT {session_uri} HTTP/1.1
Host: www.googleapis.com
Content-Length: 524288
Content-Type: image/jpeg
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 של מקטע נעצרה או אם קיבלת 503 Service Unavailable HTTP או כל תשובה 5xx אחרת מהשרת, בצעו את התהליך המתואר בהמשך העלאה שהופסקה, אך במקום להעלות את שאר הקבצים, פשוט ממשיכים בהעלאה של שאר הקבצים.

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

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

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

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

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

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

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

1) מבקשים את סטטוס ההעלאה.

בבקשה הבאה נעשה שימוש בכותרת Content-Range כדי לציין שהמיקום הנוכחי בקובץ של 2,000,000 בייטים לא ידוע.

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

2) מחלצים מהתגובה את מספר הבייטים שהועלו עד כה.

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

HTTP/1.1 308 Resume Incomplete
Content-Length: 0
Range: 0-42

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

3) ממשיכים את ההעלאה מהנקודה שבה היא נעצרה.

הבקשה הבאה תמשיך את ההעלאה על ידי שליחת הבייטים הנותרים של הקובץ, החל מבייטים 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), אבל עדיין אפשר לנסות מספר מהן. כשמנסים שוב את הבקשות האלה, כדאי להגביל את מספר הפעמים שמנסים שוב. לדוגמה, הקוד יכול להגביל לעשרה ניסיונות חוזרים או פחות לפני דיווח על שגיאה.
כדי לטפל בשגיאות 404 Not Found ו-410 Gone, כשמבצעים העלאות שניתן להמשיך, צריך להתחיל את ההעלאה כולה מההתחלה.

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

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

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

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

שולחים בקשה ל-API.
מקבלים את התשובה HTTP 503, שמצביעה על כך שצריך לנסות שוב את הבקשה.
ממתינים 1 שנייה + random_number_milliseconds ומנסים שוב את הבקשה.
תקבלו תגובה מסוג HTTP 503, שמציינת שצריך לנסות שוב את הבקשה.
צריך להמתין 2 שניות +Android_number_milliseconds, ולנסות שוב את הבקשה.
תקבלו תגובה מסוג HTTP 503, שמציינת שצריך לנסות שוב את הבקשה.
ממתינים 4 שניות + random_number_milliseconds ומנסים שוב את הבקשה.
מקבלים את התשובה HTTP 503, שמצביעה על כך שצריך לנסות שוב את הבקשה.
ממתינים 8 שניות + random_number_milliseconds ומנסים שוב את הבקשה.
מקבלים את התשובה HTTP 503, שמצביעה על כך שצריך לנסות שוב את הבקשה.
צריך להמתין 16 שניות +GCLID_number_milliseconds, ולנסות שוב את הבקשה.
הפסקת ההפעלה. דיווח על שגיאה או רישום שלה ביומן.

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

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

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