الحدود القصوى والحصص للاستخدام

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

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

إذا كانت طلباتك بحاجة إلى إكمالها في فترة زمنية ثابتة، أرسِل طلباتك بالتوازي أو استخدِم سلاسل محادثات متعددة في تطبيق Java أو C#. من الأمثلة على الطلبات المتوازية طلب مجموعات صغيرة من الرسائل الإلكترونية من مستخدمين مختلفين بدلاً من إضافة أو إزالة الكثير من الرسائل الإلكترونية من مستخدم واحد في الوقت نفسه. في ما يتعلّق بسلاسل المحادثات، جرِّب البدء بـ 10 سلاسل محادثات، أي سلسلة محادثات واحدة لكل عنوان بريد إلكتروني للمستخدم. يُرجى العِلم أنّ اقتراح سلسلة المحادثات له مزايا وعيوب، ولا يكون مفيدًا في جميع حالات استخدام واجهة برمجة التطبيقات. إذا ارتفع عدد الطلبات بشكل كبير جدًا، ستحدث أخطاء في الحصة.

بالنسبة إلى جميع الأخطاء المستندة إلى الوقت (بحد أقصى N عنصر لمدة N ثانية لكل سلسلة محادثات)، وخاصةً أخطاء رمز الحالة 503، ننصح بأن يرصد الرمز الاستثناء، وأن ينتظر فترة تأخير قصيرة قبل إعادة محاولة إجراء المكالمة التي تعذّر إجراؤها، وذلك باستخدام خوارزمية التراجع الأسي. أحد الأمثلة على Alert Center API لسلسلة محادثات واحدة هو الانتظار لمدة 5 ثوانٍ وإعادة محاولة المكالمة التي تعذّر إجراؤها. إذا نجح الطلب، كرِّر هذا النمط لسلاسل التعليمات الأخرى. إذا لم ينجح الطلب الثاني، يجب أن يخفّض تطبيقك من معدّل تكرار الطلب إلى أن ينجح أحد الطلبات. على سبيل المثال، يمكنك زيادة فترة التأخير الأولية البالغة 5 ثوانٍ إلى 10 ثوانٍ وإعادة محاولة إجراء المكالمة التي تعذّر إجراؤها. حدِّد أيضًا عدد محاولات إعادة التشغيل. على سبيل المثال، أعِد محاولة تنفيذ الطلب من 5 إلى 7 مرات مع فترات تأخير مختلفة قبل أن يعرض تطبيقك رسالة خطأ للمستخدم.

فئات حدود واجهة برمجة التطبيقات الحدود
معدّلات طلبات البحث في الثانية وطلبات البحث في اليوم في "مركز التنبيه" تفرض واجهة برمجة التطبيقات حدًا أقصى على عدد الطلبات لمشروعك في "وحدة تحكّم واجهة برمجة التطبيقات". الحدّ الأقصى لعدد الطلبات في الثانية لمشروع واجهة برمجة التطبيقات (QPS للمشروع) هو 1000. والحد الأقصى لعدد الطلبات لكل مستخدم في الثانية (طلبات البحث في الثانية لكل مستخدم) هو 150.

في حال تجاوز هذه الحدود، يعرض الخادم رمز الحالة 503 لبروتوكول HTTP. استخدِم خوارزمية التراجع السريع للغاية عند إعادة محاولة إرسال طلباتك.

أنواع أخرى من الحدود القيود والإرشادات
تنسيق البيانات، الإعداد التلقائي تنسيق البيانات التلقائي هو JSON.
الطلبات غير المصرّح بها لا تسمح Google بالطلبات غير المصرّح بها إلى واجهة برمجة التطبيقات هذه. يُعدّ الطلب غير مصرّح به إذا لم يتم تقديم رمز تفويض. لمزيد من المعلومات، يُرجى الاطّلاع على تفويض الطلبات.

طلب زيادة الحصة لكل مشروع

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

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

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