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

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

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

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

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

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

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

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

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

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

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

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