حدود الاستخدام

بما أنّ Google Meet REST API هي خدمة مشترَكة، نفرض حصصًا وقيودًا لضمان استخدامها بشكل عادل من قِبل جميع المستخدمين وحماية الأداء العام لنظام Google Workspace.

إذا تجاوزت حصة معيّنة، ستتلقّى بشكل عام استجابة برمز حالة HTTP هو 429: Too many requests. وفي هذه الحالة، عليك استخدام خوارزمية الرقود الأسي الثنائي وإعادة المحاولة لاحقًا. طالما أنّك تلتزم بالحِصص المحدّدة لكل دقيقة، ليس هناك حدّ لعدد الطلبات التي يمكنك إجراؤها في اليوم الواحد.

يوضّح الجدول التالي تفاصيل حدود طلبات البحث:

الحصص
طلبات القراءة
لكل دقيقة لكل مشروع 6000
لكل دقيقة لكل مستخدم لكل مشروع 600
طلبات الكتابة
لكل دقيقة لكل مشروع 1000
لكل دقيقة لكل مستخدم لكل مشروع 100
طلبات الكتابة المخفّضة

(تُستخدَم لطلبات spaces.create)

لكل دقيقة لكل مشروع 100
لكل دقيقة لكل مستخدم لكل مشروع 10

معالجة أخطاء الحصص المستندة إلى الوقت

بالنسبة إلى جميع الأخطاء المستندة إلى الوقت (الحد الأقصى لعدد N من الطلبات لكل X دقيقة)، ننصحك بأن يرصد الرمز البرمجي الاستثناء ويستخدم خوارزمية الرقود الأسي الثنائي المقتطَعة لضمان عدم تحميل أجهزتك حملاً زائدًا.

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

مثال على خوارزمية

تعيد خوارزمية الرقود الأسي الثنائي محاولة إرسال الطلبات بشكل أسي، ما يؤدي إلى زيادة وقت الانتظار بين عمليات إعادة المحاولة حتى الحد الأقصى لوقت الرقود. على سبيل المثال:

  1. أرسِل طلبًا إلى Google Meet API.
  2. إذا تعذّر تنفيذ الطلب، انتظِر 1 + random_number_milliseconds وأعِد محاولة إرسال الطلب.
  3. إذا تعذّر تنفيذ الطلب، انتظِر 2 + random_number_milliseconds وأعِد محاولة إرسال الطلب.
  4. إذا تعذّر تنفيذ الطلب، انتظِر 4 + random_number_milliseconds وأعِد محاولة إرسال الطلب.
  5. وهكذا، حتى وقت maximum_backoff.
  6. استمر في الانتظار وإعادة المحاولة حتى عدد أقصى من عمليات إعادة المحاولة، ولكن لا تزد فترة الانتظار بين عمليات إعادة المحاولة.

حيث:

  • وقت الانتظار هو 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 ثانية. في مرحلة معيّنة، يجب منع العملاء من إعادة المحاولة إلى أجل غير مسمّى.

يعتمد وقت الانتظار بين عمليات إعادة المحاولة وعدد عمليات إعادة المحاولة على حالة الاستخدام وظروف الشبكة.

الأسعار

يتوفّر كل الاستخدام العادي لـ Google Meet API بدون أي تكلفة إضافية. من المُخطّط أن يتم فرض رسوم على حساب الفوترة في Google Cloud في وقت لاحق من عام 2026 عند تجاوز حدود طلبات الحصص. لمزيد من المعلومات، يُرجى الاطّلاع على مقالة نموذج Google Workspace الموحّد لأدوات الوكلاء وواجهات برمجة التطبيقات.

طلب زيادة الحصة

بناءً على استخدام مشروعك للموارد، قد تحتاج إلى طلب تعديل الحصة. تُعتبَر طلبات واجهة برمجة التطبيقات التي يرسلها حساب خدمة مستخدِمة لحساب واحد. لا يضمن التقدم بطلب للحصول على حصة معدَّلة الموافقة. قد تستغرق طلبات تعديل الحصص التي ستؤدي إلى زيادة قيمة الحصة بشكل ملحوظ وقتًا أطول للموافقة عليها.

لا تتساوى الحصص في جميع المشاريع. مع زيادة استخدامك لـ Google Cloud بمرور الوقت، قد تحتاج إلى زيادة قيم الحصص. إذا كنت تتوقّع زيادة ملحوظة في الاستخدام في المستقبل القريب، يمكنك طلب تعديلات الحصص بشكل استباقي من صفحة الحصص وحدود النظام في Google Cloud Console.

لمزيد من المعلومات، يُرجى الاطّلاع على المَراجع التالية: