حول تحميل الوسائط

تسمح لك واجهة برمجة تطبيقات Google Mirror بإدخال مرفق عند إنشاء عنصر جديد في المخطط الزمني.

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

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

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

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

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

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

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

    مثال: POST /upload/mirror/v1/timeline

  • معرّف الموارد المنتظم (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: اضبط أحد أنواع بيانات وسائط التحميل المقبولة للطريقة، والمحدّدة في مرجع واجهة برمجة التطبيقات.
  • Content-Length. اضبط على عدد وحدات البايت التي تحمّلها. ليس مطلوبًا إذا كنت تستخدم تشفير النقل المقسم.

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

يوضح المثال التالي استخدام طلب تحميل بسيط لواجهة برمجة تطبيقات Google Mirror.

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

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

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. اضبُط على الجزء المتعدّد/ذات الصلة وأدرِج سلسلة الحدود التي تستخدمها لتحديد أجزاء الطلب.
  • Content-Length. اضبط هذا الإعداد على إجمالي عدد وحدات البايت في نص الطلب. يجب أن يكون جزء الوسائط في الطلب أقل من الحد الأقصى لحجم الملف المحدد لهذه الطريقة.

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

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

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

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

ملاحظة: لإنشاء جزء البيانات الوصفية فقط أو تحديثه، بدون تحميل البيانات المقترنة، أرسل ببساطة طلب POST أو PUT إلى نقطة نهاية المورد القياسية: https://www.googleapis.com/mirror/v1/timeline

مثال: تحميل مقاطع متعددة

يعرض المثال أدناه طلب تحميل متعدد الأجزاء لواجهة برمجة تطبيقات Google Mirror.

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--

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

HTTP/1.1 200
Content-Type: application/json

{
  "text": "Hello world!"
}

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

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

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

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

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

ملاحظة: تنتهي صلاحية معرّف الموارد المنتظم (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. يُرجى ضبط عدد وحدات البايت المقدمة في نص هذا الطلب المبدئي. ليس مطلوبًا إذا كنت تستخدم تشفير النقل المقسم.

اطلع على مرجع واجهة برمجة التطبيقات لقائمة كل طريقة لأنواع 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) للجلسة القابلة للاستئناف

في حال نجاح طلب بدء الجلسة، سيستجيب خادم واجهة برمجة التطبيقات برمز حالة 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 بالكامل بحجم 2000000 بايت للمثال الحالي.

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. كما يتيح لك أيضًا تنفيذ إجراءات، مثل تقديم مؤشرات تقدُّم التحميل للمتصفحات القديمة التي لا يتوفر بها دعم تقدم التحميل بشكل افتراضي.

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

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

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

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

  2. الحصول على عدد وحدات البايت التي تم تحميلها معالجة الاستجابة من استعلام الحالة. يستخدم الخادم رأس Range في استجابته لتحديد وحدات البايت التي تلقاها حتى الآن. على سبيل المثال، يشير العنوان Range الذي يبلغ 0-299999 إلى أنه قد تم استلام أول 300,000 بايت من الملف.
  3. تحميل البيانات المتبقية: وأخيرًا، بعد أن عرفت أين يمكنك استئناف الطلب، أرسِل البيانات المتبقية أو المجموعة الحالية. تجدر الإشارة إلى أنك تحتاج إلى التعامل مع البيانات المتبقية كمجموعة منفصلة في كلتا الحالتين، لذا يجب إرسال الرأس Content-Range عند استئناف التحميل.
مثال: استئناف عملية تحميل تمت مقاطعتها

1) اطلب حالة التحميل.

يستخدم الطلب التالي الرأس Content-Range للإشارة إلى أن الموضع الحالي في ملف 2000000 بايت غير معروف.

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. يُرجى الانتظار لمدة ثانيتَين +Random_number_milliseconds، ثم إعادة محاولة الطلب.
  6. يمكنك تلقّي استجابة HTTP 503 تشير إلى أنه يجب إعادة محاولة الطلب.
  7. انتظِر لمدة 4 ثوانٍ + عشوائية_number_milliseconds، ثم أعِد محاولة الطلب.
  8. يمكنك تلقّي استجابة HTTP 503 تشير إلى أنه يجب إعادة محاولة الطلب.
  9. انتظِر لمدة 8 ثوانٍ + عشوائية_number_milliseconds، ثم أعِد محاولة الطلب.
  10. يمكنك تلقّي استجابة HTTP 503 تشير إلى أنه يجب إعادة محاولة الطلب.
  11. انتظِر لمدة 16 ثانية + عشوائية_number_milliseconds، ثم أعِد محاولة الطلب.
  12. إيقاف. الإبلاغ عن خطأ أو تسجيله.

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

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

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

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