جارٍ تحميل الملفات

تتيح لك واجهة برمجة تطبيقات Google Play Developer API تحميل الصور أو apks أو ملفات التوسيع لإجراء تعديل. نستخدم أدناه الصور كمثال.

خيارات التحميل

تتيح لك واجهة برمجة التطبيقات Google Play Developer API تحميل أنواع معيّنة من البيانات الثنائية أو الوسائط. يتم تحديد الخصائص المحددة للبيانات التي يمكنك تحميلها في الصفحة المرجعية لأي طريقة تدعم تحميل الوسائط:

  • الحد الأقصى لحجم ملف التحميل: الحد الأقصى لحجم البيانات التي يمكنك تخزينها بهذه الطريقة.
  • أنواع MIME للوسائط المقبولة: أنواع البيانات الثنائية التي يمكنك تخزينها باستخدام هذه الطريقة.

يمكنك تقديم طلبات التحميل بأي من الطرق التالية. حدِّد الطريقة التي تستخدمها مع معلمة الطلب uploadType.

  • تحميل بسيط: uploadType=media. لنقل الملفات الأصغر حجمًا بسرعة، مثلاً 5 ميغابايت أو أقل.
  • تحميل متعدد الأجزاء: uploadType=multipart. لنقل الملفات الصغيرة والبيانات الوصفية بسرعة، يمكن نقل الملف مع البيانات الوصفية التي تصفه، وكل ذلك في طلب واحد.
  • تحميل قابل للاستئناف: uploadType=resumable. لإجراء عملية نقل موثوق بها، لا سيما مع الملفات الكبيرة الحجم. باستخدام هذه الطريقة، يمكنك استخدام طلب بدء جلسة، والذي يمكن أن يتضمن بيانات وصفية اختياريًا. وهذه استراتيجية جيدة للاستخدام مع معظم التطبيقات، لأنها تصلح أيضًا للملفات الأصغر حجمًا على حساب طلب HTTP إضافي واحد لكل عملية تحميل.

عند تحميل الوسائط، يمكنك استخدام معرّف موارد منتظم (URI) خاص. وفي الواقع، تشتمل الطرق التي تدعم تحميل الوسائط على نقطتَي نهاية لمعرّف الموارد المنتظم (URI):

  • معرّف الموارد المنتظم (URI) الذي يعمل بنظام التشغيل /upload للوسائط. ويكون تنسيق نقطة نهاية التحميل هو معرّف الموارد المنتظم (URI) العادي للمورد الذي يحمل البادئة “/upload”. استخدِم معرّف الموارد المنتظم هذا عند نقل بيانات الوسائط نفسها.

    مثال: POST /upload/androidpublisher/v3/applications/packageName/edits/editId/listings/language/imageType

  • معرّف الموارد المنتظم (URI) للمورد العادي للبيانات الوصفية. إذا كان المورد يحتوي على أي حقول بيانات، يتم استخدام هذه الحقول لتخزين البيانات الوصفية التي تصف الملف الذي تم تحميله. يمكنك استخدام معرّف الموارد المنتظم (URI) هذا عند إنشاء قيم البيانات الوصفية أو تعديلها.

    مثال: POST /androidpublisher/v3/applications/packageName/edits/editId/listings/language/imageType

تحميل بسيط

وأبسط طريقة لتحميل ملف هي عبر تقديم طلب تحميل بسيط. ويكون هذا الخيار جيدًا في الحالات التالية:

  • الملف صغير بما يكفي لتحميله مرة أخرى بالكامل إذا فشل الاتصال.
  • لا توجد بيانات وصفية لإرسالها. قد يكون ذلك صحيحًا إذا كنت تخطط لإرسال البيانات الوصفية لهذا المورد في طلب منفصل، أو إذا لم تكن هناك بيانات وصفية متوفرة أو متوفرة.

لاستخدام عملية تحميل بسيطة، يمكنك تقديم طلب POST أو PUT إلى معرّف الموارد المنتظم /upload التابع للطريقة وإضافة مَعلمة طلب البحث uploadType=media. مثال:

POST https://www.googleapis.com/upload/androidpublisher/v3/applications/packageName/edits/editId/listings/language/imageType?uploadType=media

تشتمل عناوين HTTP التي يتم استخدامها عند إجراء طلب تحميل بسيط على ما يلي:

  • Content-Type. يتم الضبط على أحد أنواع بيانات وسائط التحميل المقبولة والمحددة في مرجع واجهة برمجة التطبيقات.
  • Content-Length. اضبط عدد وحدات البايت التي تحمِّلها. غير مطلوب إذا كنت تستخدم ترميز نقل مقطوع.

مثال: تحميل بسيط

يوضِّح المثال التالي استخدام طلب تحميل بسيط لواجهة برمجة التطبيقات Google Play Developer API.

POST /upload/androidpublisher/v3/applications/packageName/edits/editId/listings/language/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

إذا نجح الطلب، سيعرض الخادم رمز حالة HTTP 200 OK مع أي بيانات وصفية:

HTTP/1.1 200
Content-Type: application/json

{
 
"image": {
   
"id": string,
   
"url": string,
   
"sha1": string
 
}
}

تحميل متعدد الأجزاء

إذا كانت لديك بيانات وصفية تريد إرسالها مع البيانات التي تريد تحميلها، يمكنك تقديم طلب multipart/related واحد. يعد هذا اختيارًا جيدًا إذا كانت البيانات التي ترسلها صغيرة بما يكفي لتحميلها مرة أخرى بالكامل إذا فشل الاتصال.

لاستخدام التحميل المتعدد الأجزاء، يمكنك تقديم طلب POST أو PUT إلى معرّف الموارد المنتظم /upload الخاص بالطريقة وإضافة مَعلمة طلب البحث uploadType=multipart، على سبيل المثال:

POST https://www.googleapis.com/upload/androidpublisher/v3/applications/packageName/edits/editId/listings/language/imageType?uploadType=multipart

تتضمن عناوين HTTP ذات المستوى الأعلى التي يتم استخدامها عند تقديم طلب تحميل متعدد الأجزاء ما يلي:

  • Content-Type. اضبطها على متعدد الأجزاء/ذات صلة وضمِّن سلسلة الحدود التي تستخدمها لتحديد أجزاء الطلب.
  • Content-Length: يتم الضبط على إجمالي عدد وحدات البايت في نص الطلب. يجب أن يكون جزء الوسائط في الطلب أقل من الحد الأقصى لحجم الملف المحدَّد لهذه الطريقة.

يتم تنسيق نص الطلب كنوع محتوى multipart/related [RFC2387] ويحتوي على جزأين بالضبط. يتم تحديد الأجزاء بواسطة سلسلة حدودية، وتتبع سلسلة الحدود النهائية شَرطتين.

يحتاج كل جزء من الطلب المتعدّد الأجزاء إلى عنوان Content-Type إضافي:

  1. جزء البيانات الوصفية: يجب أن يأتي أولاً، ويجب أن يتطابق Content-Type مع أحد تنسيقات البيانات الوصفية المقبولة.
  2. جزء الوسائط: يجب أن يظهر ثانيًا، ويجب أن يتطابق Content-Type مع أحد أنواع MIME للوسائط المقبولة.

يمكنك الاطّلاع على مرجع واجهة برمجة التطبيقات الخاص بكل قائمة بأنواع MIME للوسائط المقبولة وحدود الحجم للملفات التي يتم تحميلها.

ملاحظة: لإنشاء جزء من البيانات الوصفية أو تعديله فقط، بدون تحميل البيانات المرتبطة، ما عليك سوى إرسال طلب POST أو PUT إلى نقطة نهاية المورد العادية: https://www.googleapis.com/androidpublisher/v3/applications/packageName/edits/editId/listings/language/imageType

مثال: تحميل متعدد الأجزاء

يوضّح المثال أدناه طلب تحميل متعدد الأجزاء لواجهة Google Play Developer API.

POST /upload/androidpublisher/v3/applications/packageName/edits/editId/listings/language/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

{
 
"image": {
   
"id": string,
   
"url": string,
   
"sha1": string
 
}
} --foo_bar_baz Content-Type: image/png PNG data --foo_bar_baz--

إذا نجح الطلب، سيعرض الخادم رمز حالة HTTP 200 OK مع أي بيانات وصفية:

HTTP/1.1 200
Content-Type: application/json

{
 
"image": {
   
"id": string,
   
"url": string,
   
"sha1": string
 
}
}

تحميل قابل للاستئناف

لتحميل ملفات البيانات بشكل أكثر موثوقية، يمكنك استخدام بروتوكول التحميل القابل للاستئناف. يتيح لك هذا البروتوكول استئناف عملية التحميل بعد أن يؤدي فشل الاتصال إلى مقاطعة تدفق البيانات. وهو مفيد على وجه الخصوص إذا كنت تنقل ملفات كبيرة الحجم واحتمال حدوث انقطاع في الشبكة أو فشل إرسال آخر مرتفع، على سبيل المثال، عند التحميل من تطبيق عميل جوّال. ويمكن أن يؤدي ذلك أيضًا إلى تقليل استخدام النطاق الترددي في حالة تعطل الشبكة لأنه لن تضطر إلى إعادة تشغيل عمليات تحميل الملفات الكبيرة من البداية.

تتضمن خطوات استخدام التحميل القابل للاستئناف ما يلي:

  1. بدء جلسة قابلة للاستئناف. يمكنك تقديم طلب أوّلي إلى معرّف الموارد المنتظم (URI) للتحميل الذي يتضمّن البيانات الوصفية، إن توفّرت.
  2. احفظ عنوان URL للجلسة القابلة للاستئناف. احفظ معرّف الموارد المنتظم (URI) للجلسة الذي تم عرضه كاستجابة للطلب الأولي، وستستخدمه للطلبات المتبقية في هذه الجلسة.
  3. حمِّل الملف. أرسِل ملف الوسائط إلى معرّف الموارد المنتظم (URI) للجلسة القابلة للاستئناف.

بالإضافة إلى ذلك، يجب أن تحتوي التطبيقات التي تستخدم التحميل القابل للاستئناف على رمز برمجي لاستئناف تحميل تمت مقاطعته. في حال مقاطعة عملية التحميل، حدِّد كمية البيانات التي تم تلقّيها بنجاح، ثم استأنف عملية التحميل بدءًا من تلك النقطة.

ملاحظة: تنتهي صلاحية معرِّف الموارد المنتظم (URI) للتحميل بعد أسبوع واحد.

الخطوة 1: بدء جلسة قابلة للاستئناف

لبدء عملية تحميل قابلة للاستئناف، يمكنك تقديم طلب POST أو PUT إلى معرّف الموارد المنتظم /upload الخاص بالطريقة وإضافة مَعلمة طلب البحث uploadType=resumable، على سبيل المثال:

POST https://www.googleapis.com/upload/androidpublisher/v3/applications/packageName/edits/editId/listings/language/imageType?uploadType=resumable

بالنسبة إلى طلب البدء هذا، يكون النص إما فارغًا أو يحتوي على البيانات الوصفية فقط، وبالتالي ستنقل المحتوى الفعلي للملف الذي تريد تحميله في الطلبات اللاحقة.

يمكنك استخدام عناوين HTTP التالية مع الطلب الأولي:

  • X-Upload-Content-Type. اضبط نوع MIME للوسائط على بيانات التحميل المراد نقلها في الطلبات اللاحقة.
  • X-Upload-Content-Length. يتم الضبط على عدد وحدات البايت لبيانات التحميل المراد نقلها في الطلبات اللاحقة. إذا كان الطول غير معروف في وقت هذا الطلب، يمكنك حذف هذا العنوان.
  • في حال تقديم البيانات الوصفية: Content-Type. يتم ضبطها وفقًا لنوع بيانات البيانات الوصفية.
  • Content-Length: يتم الضبط على عدد وحدات البايت المقدَّمة في نص هذا الطلب الأولي. غير مطلوب إذا كنت تستخدم ترميز نقل مقطوع.

يمكنك الاطّلاع على مرجع واجهة برمجة التطبيقات الخاص بكل قائمة بأنواع MIME للوسائط المقبولة وحدود الحجم للملفات التي يتم تحميلها.

مثال: طلب بدء جلسة قابلة للاستئناف

يوضّح المثال التالي كيفية بدء جلسة قابلة للاستئناف لواجهة برمجة تطبيقات مطوّر برامج Google Play.

POST /upload/androidpublisher/v3/applications/packageName/edits/editId/listings/language/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

{
 
"image": {
   
"id": string,
   
"url": string,
   
"sha1": string
 
}
}

ملاحظة: بالنسبة إلى طلب تعديل أولي قابل للاستئناف بدون بيانات وصفية، اترك نص الطلب فارغًا، واضبط عنوان 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/androidpublisher/v3/applications/packageName/edits/editId/listings/language/imageType?uploadType=resumable&upload_id=xa298sd_sdlkj2
Content-Length: 0

قيمة العنوان Location، كما هو موضّح في نموذج الاستجابة أعلاه، هي معرّف الموارد المنتظم (URI) للجلسة الذي ستستخدمه كنقطة نهاية HTTP لإجراء التحميل الفعلي للملف أو طلب حالة التحميل.

انسخ معرّف الموارد المنتظم (URI) للجلسة واحفظه حتى تتمكّن من استخدامه للطلبات اللاحقة.

الخطوة 3: تحميل الملف

لتحميل الملف، أرسِل طلب PUT إلى معرّف الموارد المنتظم (URI) للتحميل الذي حصلت عليه في الخطوة السابقة. تنسيق طلب التحميل هو:

PUT session_uri

تتضمّن عناوين HTTP التي سيتم استخدامها عند تقديم طلبات تحميل الملفات القابلة للاستئناف Content-Length. اضبُطه على عدد وحدات البايت التي تحمِّلها في هذا الطلب، وهو حجم ملف التحميل بوجه عام.

مثال: طلب تحميل ملف قابل للاستئناف

إليك طلب قابل للاستئناف لتحميل ملف PNG بحجم 2000000 بايت بالكامل للمثال الحالي.

PUT https://www.googleapis.com/upload/androidpublisher/v3/applications/packageName/edits/editId/listings/language/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. ويتيح لك أيضًا تنفيذ إجراءات مثل تقديم مؤشرات عن تقدم التحميل للمتصفّحات القديمة التي لا يتوفر لها دعم بشأن تقدُّم التحميل بشكل تلقائي.


استئناف عملية تحميل تمت مقاطعة تحميلها

إذا تم إنهاء طلب التحميل قبل تلقّي استجابة أو إذا تلقّيت استجابة HTTP 503 Service Unavailable من الخادم، يجب استئناف عملية التحميل التي تمّت مقاطعتها. لإجراء ذلك، يُرجى اتّباع الخطوات التالية:

  1. حالة الطلب: يمكنك الاستعلام عن الحالة الحالية للتحميل من خلال إصدار طلب PUT فارغ إلى معرّف الموارد المنتظم (URI) للتحميل. بالنسبة إلى هذا الطلب، يجب أن تتضمّن عناوين HTTP عنوان Content-Range يشير إلى أنّ الموضع الحالي في الملف غير معروف. على سبيل المثال، يمكنك ضبط السمة Content-Range على */2000000 إذا كان إجمالي طول الملف 2,000,000. إذا كنت لا تعرف الحجم الكامل للملف، اضبط السمة Content-Range على */*.

    ملاحظة: يمكنك طلب عرض حالة نقل البيانات بين المقاطع، وليس فقط إذا توقف التحميل. ويكون هذا مفيدًا، على سبيل المثال، إذا كنت تريد عرض مؤشرات تقدم التحميل للمتصفّحات القديمة.

  2. الحصول على عدد وحدات البايت التي تم تحميلها معالجة الرد من طلب البحث عن الحالة. يستخدم الخادم عنوان Range في استجابته لتحديد وحدات البايت التي تلقّاها حتى الآن. على سبيل المثال، يشير عنوان Range للسمة 0-299999 إلى أنّه تم استلام أول 300,000 بايت من الملف.
  3. حمِّل البيانات المتبقية. أخيرًا، الآن بعد أن عرفت مكان استئناف الطلب، أرسل البيانات المتبقية أو المقطع الحالي. يُرجى العِلم أنّه عليك التعامل مع البيانات المتبقية كمقطع منفصل في كلتا الحالتين، وبالتالي يجب إرسال العنوان 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
  • استخدِم استراتيجية التراجع الأُسيّ في حال عرض أي خطأ في الخادم 5xx عند استئناف طلبات التحميل أو إعادة محاولة تحميلها. يمكن أن تحدث هذه الأخطاء في حال زيادة التحميل على الخادم. يمكن أن يساعد التراجع الأسي في التخفيف من هذه الأنواع من المشكلات خلال فترات ارتفاع حجم الطلبات أو حركة بيانات الشبكة الكثيفة.
  • يجب عدم التعامل مع الأنواع الأخرى من الطلبات من خلال ميزة "التراجع الأسي" ولكن لا يزال بإمكانك إعادة محاولة إجراء عدد منها. عند إعادة محاولة تنفيذ هذه الطلبات، عليك تحديد عدد المرّات التي تعيد فيها المحاولة. على سبيل المثال، قد يقتصر الرمز الخاص بك على عشر محاولات أو أقل قبل الإبلاغ عن خطأ.
  • يجب التعامل مع أخطاء 404 Not Found و410 Gone عند إجراء عمليات تحميل قابلة للاستئناف، وذلك عن طريق بدء التحميل بالكامل من البداية.

تراجع أسي

يعتبر التراجع التزايدي استراتيجية قياسية لمعالجة الأخطاء لتطبيقات الشبكة التي يعيد فيها العميل بشكل دوري محاولة تنفيذ طلب إخفاق على مدار فترة زمنية متزايدة. إذا تسببت كمية كبيرة من الطلبات أو حركة مرور بيانات الشبكة الكثيفة في عرض الخادم لأخطاء، فقد يكون التراجع الأسي استراتيجية جيدة للتعامل مع هذه الأخطاء. وبالعكس، فهي ليست استراتيجية مناسبة للتعامل مع الأخطاء غير المرتبطة بحجم الشبكة أو أوقات الاستجابة، مثل بيانات اعتماد التفويض غير الصالحة أو أخطاء "لم يتم العثور على الملف".

يؤدي استخدام ميزة "التراجع الأسي" إلى زيادة كفاءة استخدام معدل نقل البيانات، وتقليل عدد الطلبات المطلوبة للحصول على استجابة ناجحة، وزيادة سرعة معالجة الطلبات في البيئات المتزامنة.

في ما يلي الخطوات التي يجب اتّباعها لتنفيذ تراجع أسي بسيط:

  1. يمكنك تقديم طلب إلى واجهة برمجة التطبيقات.
  2. يتم تلقّي استجابة HTTP 503، ما يشير إلى أنّه يجب إعادة محاولة الطلب.
  3. يُرجى الانتظار لمدة ثانية واحدة مع قيمة عشوائية لـ العشوائي_number_milliseconds وإعادة محاولة الطلب.
  4. يتم تلقّي استجابة HTTP 503، ما يشير إلى أنّه يجب إعادة محاولة الطلب.
  5. انتظِر لمدة ثانيتين مع إضافة عشوائي_number_milliseconds، وأعِد محاولة إجراء الطلب.
  6. يتم تلقّي استجابة HTTP 503، ما يشير إلى أنّه يجب إعادة محاولة الطلب.
  7. انتظِر لمدة 4 ثوانٍ + العشوائي_number_milliseconds، ثم أعِد محاولة إجراء الطلب.
  8. يتم تلقّي استجابة HTTP 503، ما يشير إلى أنّه يجب إعادة محاولة الطلب.
  9. انتظِر لمدة 8 ثوانٍ مع إضافة عشوائي_number_milliseconds، ثم أعِد محاولة إجراء الطلب.
  10. يتم تلقّي استجابة HTTP 503، ما يشير إلى أنّه يجب إعادة محاولة الطلب.
  11. انتظِر لمدة 16 ثانية بالإضافة إلى قيمة عشوائية قدرها 16 ثانية عشوائيًا، ثم أعِد محاولة إجراء الطلب.
  12. إيقاف. الإبلاغ عن خطأ أو تسجيله

في التدفق أعلاه، alternate_number_milliseconds هو عدد عشوائي بالملي ثانية أقل من أو يساوي 1000. ويعد هذا أمرًا ضروريًا، نظرًا لأن إدخال تأخير عشوائي صغير يساعد في توزيع التحميل بشكل متساوٍ وتجنب إمكانية ختم الخادم. يجب إعادة تحديد قيمة عشوائية number_number_milliseconds بعد كل انتظار.

ملاحظة: يكون وقت الانتظار دائمًا (2 ^ n) + العشوائي_number_milliseconds، حيث يمثِّل n عددًا صحيحًا متزايدًا ويتضاعف مع تحديده في البداية على أنّه 0. تتم زيادة العدد الصحيح n بمقدار 1 لكل تكرار (كل طلب).

يتم تعيين الخوارزمية على الانتهاء عندما تكون n هي 5. ويمنع هذا الحد الأقصى للعملاء من تكرار المحاولة إلى ما لا نهاية، ويؤدي إلى تأخير إجمالي يصل إلى 32 ثانية تقريبًا قبل أن يتم تصنيف الطلب على أنه "خطأ لا يمكن إصلاحه". لا بأس في زيادة الحد الأقصى لعدد عمليات إعادة المحاولة، خاصةً إذا كان هناك تحميل طويل قيد التقدم؛ فقط تأكد من تحديد مدة تأخير إعادة المحاولة بأقل من دقيقة واحدة على سبيل المثال.

أدلة مكتبة عملاء واجهة برمجة التطبيقات