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

מידע על העלאת מדיה

Google Mirror API מאפשר להוסיף קובץ מצורף כשיוצרים פריט חדש בציר הזמן.

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

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

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

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

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

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

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

העלאה פשוטה

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

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

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

POST https://www.googleapis.com/upload/mirror/v1/timeline?uploadType=media

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

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

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

הדוגמה הבאה מציגה שימוש בבקשת העלאה פשוטה בשביל Google Mirror API.

POST /upload/mirror/v1/timeline?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

{
  "text": "Hello world!"
}

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

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

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

POST https://www.googleapis.com/upload/mirror/v1/timeline?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/mirror/v1/timeline

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

בדוגמה הבאה מוצגת בקשה של העלאה מרובת חלקים עבור Google Mirror API.

POST /upload/mirror/v1/timeline?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

{
  "text": "Hello world!"
}

--foo_bar_baz
Content-Type: image/jpeg

JPEG data
--foo_bar_baz--

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

HTTP/1.1 200
Content-Type: application/json

{
  "text": "Hello world!"
}

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

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

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

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

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

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

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

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

POST https://www.googleapis.com/upload/mirror/v1/timeline?uploadType=resumable

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

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

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

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

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

הדוגמה הבאה מראה איך להתחיל סשן שניתן להמשיך ב-Google Mirror

POST /upload/mirror/v1/timeline?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

{
  "text": "Hello world!"
}

הערה: בבקשת עדכון ראשונית שניתן להמשיך ללא מטא-נתונים, צריך להשאיר את גוף הבקשה ריק ולהגדיר את הכותרת 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/mirror/v1/timeline?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/mirror/v1/timeline?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 1,024 x 2) בקובץ בגודל 2,000,000 בייטים.

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

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

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

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

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

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

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

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

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