بما أنّ Drive Labels API هي خدمة مشترَكة، نفرض حصصًا وحدودًا لضمان استخدامها بشكل عادل من قِبل جميع المستخدمين وحماية سلامة منظومة Google Workspace المتكاملة بشكل عام.
إذا تجاوزت الحصة، ستتلقّى بشكل عام استجابة رمز حالة HTTP 429: Too many
requests. في حال حدوث ذلك، عليك استخدام
خوارزمية الرقود الأسي الثنائي وإعادة المحاولة لاحقًا.
ما دمت تلتزم بالحصة المخصّصة لكل دقيقة أدناه، ليس هناك حدّ لعدد الطلبات التي يمكنك إجراؤها يوميًا.
يوضّح الجدول التالي حدود الطلبات:
| الحصص | |||
|---|---|---|---|
| طلبات القراءة |
|
||
| كتابة الطلبات |
|
||
حلّ أخطاء الحصة المستندة إلى الوقت
بالنسبة إلى جميع الأخطاء المستندة إلى الوقت (بحد أقصى N طلب في كل X دقيقة)، ننصح بأن يرصد الرمز البرمجي الاستثناء ويستخدم تراجعًا أسيًا مقتطعًا للتأكّد من أنّ أجهزتك لا تُحمّل عبئًا مفرطًا.
التمهّل الأسي هو استراتيجية معيارية للتعامل مع الأخطاء في تطبيقات الشبكة. تعيد خوارزمية الرقود الأسي الثنائي محاولة إرسال الطلبات باستخدام فترات انتظار متزايدة بشكل أسي بين الطلبات، وذلك حتى بلوغ الحد الأقصى لوقت الرقود الأسي الثنائي. إذا استمر تعذّر تنفيذ الطلبات، من المهم زيادة حالات التأخير بين الطلبات بمرور الوقت إلى أن يتم تنفيذ الطلب بنجاح.
مثال على الخوارزمية
تعيد خوارزمية الرقود الأسي الثنائي محاولة إرسال الطلبات بشكل أسي، ما يؤدي إلى زيادة وقت الانتظار بين عمليات إعادة المحاولة إلى أن يصل إلى الحد الأقصى لوقت الرقود الأسي الثنائي. على سبيل المثال:
- إرسال طلب إلى Drive Labels API
- إذا تعذّر تنفيذ الطلب، انتظِر لمدة 1 +
random_number_millisecondsوأعِد محاولة تنفيذ الطلب. - في حال تعذّر إرسال الطلب، انتظِر لمدة 2 +
random_number_millisecondsوأعِد محاولة إرساله. - في حال تعذّر تنفيذ الطلب، انتظِر 4 ثوانٍ +
random_number_millisecondsثم أعِد محاولة تنفيذ الطلب. - وهكذا، حتى
maximum_backoffمرة. - واصِل الانتظار وإعادة المحاولة حتى بلوغ الحدّ الأقصى لعدد المحاولات، ولكن لا تزد فترة الانتظار بين المحاولات.
where:
- يبلغ وقت الانتظار
min(((2^n)+random_number_milliseconds), maximum_backoff)، مع زيادةnبمقدار 1 لكل تكرار (طلب). -
random_number_millisecondsهو عدد عشوائي من المللي ثانية أقل من أو يساوي 1,000. يساعد ذلك في تجنُّب الحالات التي تتم فيها مزامنة العديد من العملاء بسبب بعض الحالات، ثم يعيدون المحاولة مرة واحدة، ويرسلون الطلبات في موجات متزامنة. تتم إعادة احتساب قيمةrandom_number_millisecondsبعد كل محاولة إعادة إرسال الطلب. - تبلغ مدة
maximum_backoffعادةً 32 أو 64 ثانية. تعتمد القيمة المناسبة على حالة الاستخدام.
يمكن للعميل مواصلة إعادة المحاولة بعد بلوغ الوقت maximum_backoff.
لا تحتاج عمليات إعادة المحاولة بعد هذه النقطة إلى مواصلة زيادة وقت التراجع. على سبيل المثال، إذا استخدم العميل وقت maximum_backoff يبلغ 64 ثانية، يمكنه إعادة المحاولة كل 64 ثانية بعد الوصول إلى هذه القيمة. في مرحلة ما، يجب منع البرامج من إعادة المحاولة إلى أجل غير مسمّى.
يعتمد وقت الانتظار بين عمليات إعادة المحاولة وعددها على حالة الاستخدام وظروف الشبكة.
الأسعار
يتوفّر كل الاستخدام العادي لواجهة برمجة التطبيقات Drive Labels API بدون أي تكلفة إضافية. من المقرر أن يتم تحصيل رسوم من حساب الفوترة على Google Cloud في وقت لاحق من عام 2026 في حال تجاوز حدود طلبات الحصة. لمزيد من المعلومات، يُرجى الاطّلاع على نموذج Google Workspace الموحّد لأدوات الوكلاء وواجهات برمجة التطبيقات.
طلب زيادة الحصة
بناءً على استخدامك للموارد في مشروعك، قد تحتاج إلى طلب تعديل الحصة. تُعدّ طلبات البيانات من واجهة برمجة التطبيقات التي يرسلها حساب خدمة على أنّها تستخدم حسابًا واحدًا. لا يضمن التقدم بطلب للحصول على حصة معدَّلة الموافقة. قد تستغرق طلبات تعديل الحصة التي تؤدي إلى زيادة كبيرة في قيمة الحصة وقتًا أطول للموافقة عليها.
لا تتساوى جميع المشاريع في الحصص. مع زيادة استخدامك لخدمات Google Cloud بمرور الوقت، قد تحتاج إلى زيادة قيم الحصة. إذا كنت تتوقّع زيادة ملحوظة في الاستخدام قريبًا، يمكنك طلب تعديلات على الحصة بشكل استباقي من صفحة الحصص والحدود القصوى للنظام في "وحدة تحكّم Google Cloud".
لمزيد من المعلومات، يُرجى الاطّلاع على المراجع التالية: