تسمح لك Gmail API بتحميل بيانات الملفات عند إنشاء مسودة أو تعديلها أو عند إدراج رسالة أو إرسالها.
خيارات التحميل
تسمح لك Gmail API بتحميل أنواع معيّنة من البيانات الثنائية أو الوسائط. يتم تحديد الخصائص المحدّدة للبيانات التي يمكنك تحميلها في صفحة المرجع لأي طريقة تتيح تحميل الوسائط:
- الحد الأقصى لحجم ملف التحميل: الحد الأقصى لكمية البيانات التي يمكنك تخزينها باستخدام هذه الطريقة.
- أنواع MIME للوسائط المقبولة: أنواع البيانات الثنائية التي يمكنك تخزينها باستخدام هذه الطريقة.
يمكنك إرسال طلبات التحميل بأي من الطرق التالية. حدِّد الطريقة التي تستخدمها باستخدام مَعلمة طلب uploadType.
- التحميل البسيط:
uploadType=media. لنقل الملفات الصغيرة بسرعة، على سبيل المثال، 5 ميغابايت أو أقل. - التحميل المتعدد الأجزاء:
uploadType=multipart. لنقل الملفات الصغيرة والبيانات الوصفية بسرعة، يتم نقل الملف مع البيانات الوصفية التي تصفه، وكل ذلك في طلب واحد. - التحميل القابل للاستئناف:
uploadType=resumable. لنقل البيانات بشكل موثوق، وهو أمر مهم بشكل خاص مع الملفات الأكبر حجمًا. باستخدام هذه الطريقة، يمكنك استخدام طلب بدء جلسة، والذي يمكن أن يتضمّن بشكل اختياري بيانات وصفية. هذه استراتيجية جيدة لاستخدامها في معظم التطبيقات، لأنّها تعمل أيضًا مع الملفات الأصغر حجمًا مقابل طلب HTTP إضافي واحد لكل عملية تحميل.
عند تحميل الوسائط، يمكنك استخدام معرّف URI خاص. في الواقع، تحتوي الطرق التي تتيح تحميل الوسائط على نقطتَي نهاية لمعرّف URI:
معرّف URI /upload للوسائط تنسيق نقطة نهاية التحميل هو معرّف URI للمورد العادي مع بادئة "/upload". استخدِم معرّف URI هذا عند نقل بيانات الوسائط نفسها.
مثال:
POST /upload/gmail/v1/users/userId/messages/sendمعرّف URI للمورد العادي للبيانات الوصفية إذا كان المورد يحتوي على أي حقول بيانات، تُستخدم هذه الحقول لتخزين البيانات الوصفية التي تصف الملف الذي تم تحميله. يمكنك استخدام معرّف URI هذا عند إنشاء قيم البيانات الوصفية أو تعديلها.
مثال:
POST /gmail/v1/users/userId/messages/send
التحميل البسيط
إنّ الطريقة الأسهل لتحميل ملف هي إرسال طلب تحميل بسيط. هذا الخيار مناسب في الحالات التالية:
- إذا كان حجم الملف صغيرًا بما يكفي لتحميله بالكامل مرة أخرى في حال تعذّر الاتصال.
- إذا لم تكن هناك بيانات وصفية لإرسالها. قد يكون هذا صحيحًا إذا كنت تخطط لإرسال بيانات وصفية لهذا المورد في طلب منفصل، أو إذا لم تكن أي بيانات وصفية متاحة أو متوافقة.
لاستخدام التحميل البسيط، أرسِل طلب POST أو PUT إلى معرّف URI /upload الخاص بالطريقة وأضِف مَعلمة طلب البحث uploadType=media. على سبيل المثال:
POST https://www.googleapis.com/upload/gmail/v1/users/userId/messages/send?uploadType=media
تتضمّن عناوين HTTP التي يجب استخدامها عند إرسال طلب تحميل بسيط ما يلي:
Content-Type: اضبطه على أحد أنواع بيانات الوسائط المقبولة للتحميل الخاصة بالطريقة، والمحدّدة في مرجع واجهة برمجة التطبيقات .Content-Length: اضبطه على عدد وحدات البايت التي تحمّلها. ليس مطلوبًا إذا كنت تستخدم ترميز النقل المقطّع.
مثال: التحميل البسيط
يعرض المثال التالي استخدام طلب تحميل بسيط لـ Gmail API.
POST /upload/gmail/v1/users/userId/messages/send?uploadType=media HTTP/1.1 Host: www.googleapis.com Content-Type: message/rfc822 Content-Length: number_of_bytes_in_file Authorization: Bearer your_auth_token Email Message data
إذا نجح الطلب، يعرض الخادم رمز حالة HTTP 200 OK مع أي بيانات وصفية:
HTTP/1.1 200 Content-Type: application/json {
"id": string,
"threadId": string,
"labelIds": [
string
],
"snippet": string,
"historyId": unsigned long,
"payload": {
"partId": string,
"mimeType": string,
"filename": string,
"headers": [
{
"name": string,
"value": string
}
],
"body": users.messages.attachments Resource,
"parts": [
(MessagePart)
]
},
"sizeEstimate": integer,
"raw": bytes
}
التحميل المتعدد الأجزاء
إذا كان لديك بيانات وصفية تريد إرسالها مع البيانات التي سيتم تحميلها، يمكنك إرسال طلب multipart/related واحد. هذا الخيار مناسب إذا كان حجم البيانات التي ترسلها صغيرًا بما يكفي لتحميلها بالكامل مرة أخرى في حال تعذّر الاتصال.
لاستخدام التحميل المتعدد الأجزاء، أرسِل طلب POST أو PUT إلى معرّف URI /upload الخاص بالطريقة وأضِف مَعلمة طلب البحث uploadType=multipart، على سبيل المثال:
POST https://www.googleapis.com/upload/gmail/v1/users/userId/messages/send?uploadType=multipart
تتضمّن عناوين HTTP ذات المستوى الأعلى التي يجب استخدامها عند إرسال طلب تحميل متعدد الأجزاء ما يلي:
Content-Type: اضبطه على multipart/related وأضِف سلسلة الحدود التي تستخدمها لتحديد أجزاء الطلب.Content-Length: اضبطه على إجمالي عدد وحدات البايت في نص الطلب. يجب أن يكون جزء الوسائط في الطلب أقل من الحد الأقصى لحجم الملف المحدّد لهذه الطريقة.
يتم تنسيق نص الطلب كنوع محتوى multipart/related [RFC2387] ويحتوي على جزأَين فقط. يتم تحديد الأجزاء من خلال سلسلة حدود، ويتبع سلسلة الحدود النهائية شرطتان.
يحتاج كل جزء من طلب التحميل المتعدد الأجزاء إلى عنوان Content-Type إضافي:
- جزء البيانات الوصفية: يجب أن يظهر أولاً، ويجب أن يتطابق
Content-Typeمع أحد تنسيقات البيانات الوصفية المقبولة. - جزء الوسائط: يجب أن يظهر ثانيًا، ويجب أن يتطابق
Content-Typeمع أحد أنواع MIME للوسائط المقبولة الخاصة بالطريقة.
راجِع مرجع واجهة برمجة التطبيقات للاطّلاع على قائمة أنواع MIME للوسائط المقبولة والحدود القصوى لحجم الملفات التي تم تحميلها لكل طريقة.
ملاحظة: لإنشاء جزء البيانات الوصفية أو تعديله
فقط، بدون تحميل البيانات المرتبطة، ما عليك سوى إرسال طلب POST أو PUT إلى نقطة نهاية المورد العادية:
https://www.googleapis.com/gmail/v1/users/userId/messages/send
مثال: التحميل المتعدد الأجزاء
يعرض المثال أدناه طلب تحميل متعدد الأجزاء لـ Gmail API.
POST /upload/gmail/v1/users/userId/messages/send?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 {
"id": string,
"threadId": string,
"labelIds": [
string
],
"snippet": string,
"historyId": unsigned long,
"payload": {
"partId": string,
"mimeType": string,
"filename": string,
"headers": [
{
"name": string,
"value": string
}
],
"body": users.messages.attachments Resource,
"parts": [
(MessagePart)
]
},
"sizeEstimate": integer,
"raw": bytes
} --foo_bar_baz Content-Type: message/rfc822 Email Message data --foo_bar_baz--
إذا نجح الطلب، يعرض الخادم رمز حالة HTTP 200 OK مع أي بيانات وصفية:
HTTP/1.1 200 Content-Type: application/json {
"id": string,
"threadId": string,
"labelIds": [
string
],
"snippet": string,
"historyId": unsigned long,
"payload": {
"partId": string,
"mimeType": string,
"filename": string,
"headers": [
{
"name": string,
"value": string
}
],
"body": users.messages.attachments Resource,
"parts": [
(MessagePart)
]
},
"sizeEstimate": integer,
"raw": bytes
}
التحميل القابل للاستئناف
لتحميل ملفات البيانات بشكل أكثر موثوقية، يمكنك استخدام بروتوكول التحميل القابل للاستئناف. يسمح لك هذا البروتوكول باستئناف عملية تحميل بعد أن يؤدي تعذّر الاتصال إلى مقاطعة تدفق البيانات. يكون هذا البروتوكول مفيدًا بشكل خاص إذا كنت تنقل ملفات كبيرة، وكان من المرجّح حدوث انقطاع في الشبكة أو تعذّر الإرسال، على سبيل المثال، عند التحميل من تطبيق عميل على الأجهزة الجوّالة. ويمكن أن يقلّل أيضًا من استخدامك لمعدل نقل البيانات في حال حدوث أعطال في الشبكة، لأنّه ليس عليك إعادة تشغيل عمليات تحميل الملفات الكبيرة من البداية.
تشمل خطوات استخدام التحميل القابل للاستئناف ما يلي:
- بدء جلسة قابلة للاستئناف. أرسِل طلبًا أوليًا إلى معرّف URI للتحميل يتضمّن البيانات الوصفية، إن وُجدت.
- حفظ معرّف URI للجلسة القابلة للاستئناف. احفظ معرّف URI للجلسة الذي تم عرضه في ردّ الطلب الأولي، وستستخدمه للطلبات المتبقية في هذه الجلسة.
- تحميل الملف. أرسِل ملف الوسائط إلى معرّف URI للجلسة القابلة للاستئناف.
بالإضافة إلى ذلك، يجب أن تتضمّن التطبيقات التي تستخدم التحميل القابل للاستئناف رمزًا لاستئناف عملية تحميل تمّت مقاطعتها. إذا تمّت مقاطعة عملية تحميل، اطّلِع على مقدار البيانات التي تم استلامها بنجاح، ثم استأنِف عملية التحميل بدءًا من تلك النقطة.
ملاحظة: تنتهي صلاحية معرّف URI للتحميل بعد أسبوع واحد.
الخطوة 1: بدء جلسة قابلة للاستئناف
لبدء عملية تحميل قابلة للاستئناف، أرسِل طلب POST أو PUT إلى معرّف URI /upload الخاص بالطريقة وأضِف مَعلمة طلب البحث uploadType=resumable، على سبيل المثال:
POST https://www.googleapis.com/upload/gmail/v1/users/userId/messages/send?uploadType=resumable
بالنسبة إلى طلب البدء هذا، يكون نص الطلب فارغًا أو يحتوي على البيانات الوصفية فقط، وسيتم نقل المحتويات الفعلية للملف الذي تريد تحميله في الطلبات اللاحقة.
استخدِم عناوين HTTP التالية مع الطلب الأولي:X-Upload-Content-Type: اضبطه على نوع MIME للوسائط الخاصة ببيانات التحميل التي سيتم نقلها في الطلبات اللاحقة.X-Upload-Content-Length: اضبطه على عدد وحدات البايت لبيانات التحميل التي سيتم نقلها في الطلبات اللاحقة. إذا كان الطول غير معروف في وقت إرسال هذا الطلب، يمكنك حذف هذا العنوان.- إذا كنت تقدّم بيانات وصفية:
Content-Typeاضبطه وفقًا لنوع بيانات البيانات الوصفية. Content-Length: اضبطه على عدد وحدات البايت المقدّمة في نص هذا الطلب الأولي. ليس مطلوبًا إذا كنت تستخدم ترميز النقل المقطّع.
راجِع مرجع واجهة برمجة التطبيقات للاطّلاع على قائمة أنواع MIME للوسائط المقبولة والحدود القصوى لحجم الملفات التي تم تحميلها لكل طريقة.
مثال: طلب بدء جلسة قابلة للاستئناف
يعرض المثال التالي كيفية بدء جلسة قابلة للاستئناف لـ Gmail API.
POST /upload/gmail/v1/users/userId/messages/send?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: message/rfc822 X-Upload-Content-Length: 2000000 {
"id": string,
"threadId": string,
"labelIds": [
string
],
"snippet": string,
"historyId": unsigned long,
"payload": {
"partId": string,
"mimeType": string,
"filename": string,
"headers": [
{
"name": string,
"value": string
}
],
"body": users.messages.attachments Resource,
"parts": [
(MessagePart)
]
},
"sizeEstimate": integer,
"raw": bytes
}
ملاحظة: لإرسال طلب تعديل أولي قابل للاستئناف بدون بيانات وصفية، اترك نص الطلب فارغًا واضبط عنوان Content-Length على 0.
يصف القسم التالي كيفية التعامل مع الردّ.
الخطوة 2: حفظ معرّف URI للجلسة القابلة للاستئناف
إذا نجح طلب بدء الجلسة، يعرض خادم واجهة برمجة التطبيقات رمز حالة HTTP 200 OK. بالإضافة إلى ذلك، يقدّم عنوان Location يحدّد معرّف URI للجلسة القابلة للاستئناف. يتضمّن عنوان Location، الموضّح في المثال أدناه، جزءًا من مَعلمة طلب البحث upload_id التي تمنح رقم تعريف التحميل الفريد لاستخدامه في هذه الجلسة.
مثال: ردّ على طلب بدء جلسة قابلة للاستئناف
في ما يلي الردّ على الطلب في الخطوة 1:
HTTP/1.1 200 OK Location: https://www.googleapis.com/upload/gmail/v1/users/userId/messages/send?uploadType=resumable&upload_id=xa298sd_sdlkj2 Content-Length: 0
إنّ قيمة عنوان Location، كما هو موضّح في نموذج الردّ أعلاه، هي معرّف URI للجلسة الذي ستستخدمه كنقطة نهاية HTTP لإجراء عملية تحميل الملف الفعلية أو طلب حالة التحميل.
انسخ معرّف URI للجلسة واحفظه حتى تتمكّن من استخدامه للطلبات اللاحقة.
الخطوة 3: تحميل الملف
لتحميل الملف، أرسِل طلب PUT إلى معرّف URI للتحميل الذي حصلت عليه في الخطوة السابقة. تنسيق طلب التحميل هو:
PUT session_uri
تتضمّن عناوين HTTP التي يجب استخدامها عند إرسال طلبات تحميل الملف القابلة للاستئناف Content-Length. اضبط هذا العنوان على عدد وحدات البايت التي تحمّلها في هذا الطلب، وهو بشكل عام حجم ملف التحميل.
مثال: طلب تحميل ملف قابل للاستئناف
في ما يلي طلب قابل للاستئناف لتحميل ملف "رسالة إلكترونية" بالكامل بحجم 2,000,000 بايت للمثال الحالي.
PUT https://www.googleapis.com/upload/gmail/v1/users/userId/messages/send?uploadType=resumable&upload_id=xa298sd_sdlkj2 HTTP/1.1 Content-Length: 2000000 Content-Type: message/rfc822 bytes 0-1999999
إذا نجح الطلب، يعرض الخادم HTTP 201 Created، بالإضافة إلى أي بيانات وصفية مرتبطة بهذا المورد. إذا كان الطلب الأولي للجلسة القابلة للاستئناف هو PUT لتعديل مورد حالي، سيكون الردّ الناجح هو 200 OK، بالإضافة إلى أي بيانات وصفية مرتبطة بهذا المورد.
إذا تمّت مقاطعة طلب التحميل أو إذا تلقّيت الردّ HTTP 503 Service Unavailable أو أي ردّ آخر من السلسلة 5xx من الخادم، اتّبِع الإجراء الموضّح في استئناف عملية تحميل تمّت مقاطعتها.
تحميل الملف على شكل أجزاء
باستخدام عمليات التحميل القابلة للاستئناف، يمكنك تقسيم ملف إلى أجزاء وإرسال سلسلة من الطلبات لتحميل كل جزء بالتسلسل. هذا ليس الأسلوب المفضّل لأنّ هناك تكاليف أداء مرتبطة بالطلبات الإضافية، وعادةً ما يكون غير ضروري. ومع ذلك، قد تحتاج إلى استخدام التقسيم لتقليل كمية البيانات المنقولة في أي طلب واحد. يكون هذا مفيدًا عندما يكون هناك حد زمني ثابت للطلبات الفردية، كما هو الحال مع فئات معيّنة من طلبات Google App Engine. يسمح لك أيضًا بتنفيذ إجراءات مثل تقديم مؤشرات تقدّم التحميل للمتصفحات القديمة التي لا تتوافق تلقائيًا مع تقدّم التحميل.
استئناف عملية تحميل تمّت مقاطعتها
إذا تم إنهاء طلب تحميل قبل تلقّي ردّ أو إذا تلقّيت الردّ 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 */20000002) استخرِج عدد وحدات البايت التي تم تحميلها حتى الآن من الردّ.
يستخدم ردّ الخادم عنوان 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 Error502 Bad Gateway503 Service Unavailable504 Gateway Timeout
- استخدِم استراتيجية الرقود الأسي الثنائي إذا تم عرض أي خطأ في الخادم من السلسلة
5xxعند استئناف طلبات التحميل أو إعادة محاولة إرسالها. يمكن أن تحدث هذه الأخطاء إذا كان الخادم يتعرّض لحِمل زائد. يمكن أن يساعد الرقود الأسي الثنائي في التخفيف من هذه الأنواع من المشاكل خلال الفترات التي تشهد عددًا كبيرًا من الطلبات أو حركة بيانات كثيفة على الشبكة. - لا يجب معالجة أنواع الطلبات الأخرى باستخدام الرقود الأسي الثنائي، ولكن لا يزال بإمكانك إعادة محاولة إرسال عدد منها. عند إعادة محاولة إرسال هذه الطلبات، حدِّد عدد المرات التي تعيد فيها محاولة إرسالها. على سبيل المثال، يمكن أن يقتصر الرمز على عشر محاولات أو أقل قبل الإبلاغ عن خطأ.
- عالِج الأخطاء
404 Not Foundو410 Goneعند إجراء عمليات تحميل قابلة للاستئناف عن طريق بدء عملية التحميل بالكامل من البداية.
الرقود الأسي الثنائي
الرقود الأسي الثنائي هو استراتيجية معيارية لمعالجة الأخطاء في تطبيقات الشبكة، حيث يعيد العميل بشكل دوري محاولة إرسال طلب تعذّر تنفيذه على مدى فترة زمنية متزايدة. إذا كان عدد كبير من الطلبات أو حركة بيانات الشبكة الكثيفة يؤدي إلى عرض الخادم للأخطاء، قد يكون الرقود الأسي الثنائي استراتيجية جيدة لمعالجة هذه الأخطاء. في المقابل، ليس الرقود الأسي الثنائي استراتيجية مناسبة للتعامل مع الأخطاء غير المرتبطة بحجم الشبكة أو أوقات الاستجابة، مثل بيانات الاعتماد غير الصالحة للتفويض أو أخطاء عدم العثور على الملف.
عند استخدام الرقود الأسي الثنائي بشكل صحيح، يزيد من كفاءة استخدام معدل نقل البيانات، ويقلّل من عدد الطلبات المطلوبة للحصول على ردّ ناجح، ويزيد من سرعة معالجة البيانات في البيئات المتزامنة.
في ما يلي خطوات تنفيذ الرقود الأسي الثنائي البسيط:
- أرسِل طلبًا إلى واجهة برمجة التطبيقات.
- تلقَّ ردًّا
HTTP 503يشير إلى أنّه عليك إعادة محاولة إرسال الطلب. - انتظِر لمدة ثانية واحدة + random_number_milliseconds وأعِد محاولة إرسال الطلب.
- تلقَّ ردًّا
HTTP 503يشير إلى أنّه عليك إعادة محاولة إرسال الطلب. - انتظِر لمدة ثانيتَين + random_number_milliseconds وأعِد محاولة إرسال الطلب.
- تلقَّ ردًّا
HTTP 503يشير إلى أنّه عليك إعادة محاولة إرسال الطلب. - انتظِر لمدة 4 ثوانٍ + random_number_milliseconds وأعِد محاولة إرسال الطلب.
- تلقَّ ردًّا
HTTP 503يشير إلى أنّه عليك إعادة محاولة إرسال الطلب. - انتظِر لمدة 8 ثوانٍ + random_number_milliseconds وأعِد محاولة إرسال الطلب.
- تلقَّ ردًّا
HTTP 503يشير إلى أنّه عليك إعادة محاولة إرسال الطلب. - انتظِر لمدة 16 ثانية + random_number_milliseconds وأعِد محاولة إرسال الطلب.
- إيقاف أبلِغ عن خطأ أو سجِّله.
في الخطوات أعلاه، random_number_milliseconds هو عدد عشوائي من الملّي ثانية أقل من أو يساوي 1000. هذا ضروري، لأنّ إضافة تأخير عشوائي صغير يساعد في توزيع الحِمل بشكل أكثر توازنًا وتجنُّب إمكانية إرهاق الخادم. يجب إعادة تحديد قيمة random_number_milliseconds بعد كل فترة انتظار.
ملاحظة: تكون فترة الانتظار دائمًا (2 ^ n) + random_number_milliseconds، حيث n هو عدد صحيح متزايد بشكل رتيب يتم تعريفه في البداية على أنّه 0. يزداد العدد الصحيح n بمقدار 1 لكل تكرار (كل طلب).
تم ضبط الخوارزمية على الإنهاء عندما تكون قيمة n هي 5. يمنع هذا الحدّ الأقصى العملاء من إعادة المحاولة إلى ما لا نهاية، ويؤدي إلى تأخير إجمالي يبلغ حوالي 32 ثانية قبل اعتبار الطلب "خطأ غير قابل للاسترداد". لا بأس في استخدام عدد أقصى أكبر من عمليات إعادة المحاولة، خاصةً إذا كانت عملية تحميل طويلة قيد التقدّم، ولكن احرِص على تحديد الحد الأقصى لتأخير إعادة المحاولة بقيمة معقولة، مثلاً أقل من دقيقة واحدة.