تعمل بعض عمليات التكامل بشكل ممتاز في الاختبار بعشرة طلبات، ثم تبدأ بتلقي الرفض عند الحمل الفعلي. المشكلة ليست في عطل API، بل في أن وتيرة الطلبات تجاوزت الحد المسموح. سنشرح لماذا توجد الحدود أصلاً، وكيف تميّزها عن عطل الخدمة، وكيف تخفف الحمل من جهتك، ولماذا لا يسرّع الاستعلام عن الحالة كل ثانية النتيجة في الغالب.
لماذا تقيّد الخدمات معدل الطلبات
يحمي الحد البنية التحتية المشتركة: فمن دون قيد قد يستحوذ عميل واحد بسكربت عدواني على موارد يحتاج إليها الجميع. وهو كذلك توزيع عادل للقدرة، إذ يضمن الحد المفروض على كل حساب ألا يستهلك تكامل غيرك سعة النقل التي دفعت ثمنها. ويظهر الوصول إليه بصورة محددة: ترد الخدمة بالرمز 429 وكثيراً ما ترفق ترويسة بالمهلة الموصى بها قبل إعادة المحاولة. وهذا يختلف جوهرياً عن عطل الخدمة، ففي حالة العطل يتلقى جميع العملاء الخطأ في مختلف العمليات، أما التقييد فموجّه إلى مفتاحك أنت بسبب وتيرة طلباته تحديداً. وإذا جاء في الرد رمز واضح للتقييد فالبنية التحتية سليمة وتعمل بشكل طبيعي، والمشكلة في السرعة التي تطرق بها الباب لا في الخدمة.
وتيرة منتظمة بدلاً من الذروات
تُحسب كثير من الحدود ضمن نافذة زمنية، ثانية أو دقيقة. فإذا أرسلت مئة طلب دفعة واحدة ثم توقفت، ينفد عدّاد النافذة فوراً، مع أن متوسط الحمل خلال الساعة قد يكون متواضعاً. فالقيد يستجيب للذروة لا للمتوسط. أما الحجم نفسه من العمل إذا وُزّع بانتظام داخل النافذة فيمر دون أي رفض. وتسوية الوتيرة لا تعني تقليل عدد الطلبات، بل عدم تركيزها في فترة قصيرة.
قائمة الانتظار وتحديد التدفقات المتوازية من جهتك
نادراً ما تظهر المهام في التطبيق بانتظام: فقد تصل دفعة كاملة من العمل، مثلاً بعد استيراد بيانات أو عملية جماعية ينفذها المستخدم. وإذا ولّدت كل مهمة طلباً إلى API فوراً، تحولت الذروة في جهتك إلى ذروة عند حدود الخدمة. وتعالج قائمة الانتظار ذات معدل الإخراج المضبوط هذا الاختلال: تتراكم المهام في القائمة، بينما يخرج منها تدفق منتظم من الطلبات. كما ينبغي تحديد عدد الاتصالات المتوازية بـ API، فحتى مع وجود القائمة تُحدث عشرة تدفقات تضرب نقطة نهاية محدودة المعدل في وقت واحد الذروة نفسها التي يحدثها تدفق واحد بلا ضبط.
الاستعلام عن الحالة والمهلة عند الرفض
الاستعلام عن حالة العملية كل ثانية زائد عن الحاجة في الغالب: فالنتيجة لا تظهر أسرع لأنك سألت عنها أكثر. فالعملية الفعلية، مثل تسليم SMS أو إنشاء منفذ أو معالجة دفعة، يحدّها زمن الشبكة وقائمة الانتظار الداخلية للخدمة نفسها، والاستعلام بوتيرة أعلى من هذا الزمن الطبيعي لا يفعل سوى استنزاف الحصة دون تقريب الرد. والفاصل المعقول للاستعلام ينطلق من الزمن المعتاد لتنفيذ العملية، لا من الرغبة في رؤية النتيجة فوراً.
إذا تلقيت رفضاً بسبب الحد، فلا تعد إرسال الطلب فوراً بالوتيرة نفسها، لأن ذلك يطيل الحظر حتماً. الاستجابة الصحيحة هي مهلة تتزايد أسياً: تنتظر كل محاولة لاحقة مدة أطول من سابقتها، مثلاً ثانية ثم ثانيتان ثم أربع ثم ثمانٍ. وإذا أعادت الخدمة ترويسة بزمن الانتظار الموصى به، فاعتمد عليه بدلاً من تقديرك الخاص.
حدود منفصلة لكل مفتاح ومراقبة العتبة
يرتبط الحد في الغالب بمفتاح أو حساب لا بالخدمة ككل. فإذا كانت المزامنة في الخلفية وسيناريو المستخدم يستخدمان مفتاح API نفسه، فقد تلتهم مهمة خلفية ثقيلة الحصة كلها وتترك المستخدم العادي بلا رد. وتمنح المفاتيح المختلفة للمهام المختلفة عدّادات مختلفة، وهو مبدأ الفصل نفسه المتبع في API البروكسي. وينبغي أيضاً مراقبة استهلاك الحصة استباقياً: فكثير من واجهات API تعيد في الرد المتبقي منها، وبه يمكن أن تلاحظ في لوحة الحساب اقتراب العتبة قبل بدء الرفض لا بعد أول 429.
الأسئلة الشائعة
هل يمكن رفع الحد لحساب معيّن؟
عند بعض الخدمات يرتفع الحد مع الباقة، أو بطلب منفصل إلى الدعم مع وصف سيناريو الحمل. ولا ينبغي الاعتماد على ذلك مسبقاً، فالأصح تصميم التكامل وفق العتبة الحالية واعتبار التوسيع مكسباً إضافياً لا خطة.
لماذا يصلني 429 حتى مع وتيرة طلبات منخفضة؟
السبب الشائع هو مفتاح مشترك مع عملية أخرى تستهلك جزءاً من الحصة فعلاً. والثاني أن نافذة الحد أقصر مما تبدو: فالمتوسط في الدقيقة منخفض، لكن تحدث ذروات داخل الثانية الواحدة. من المفيد فحص الاحتمالين قبل تغيير منطق التكامل نفسه.
هل الحد واحد لجميع طرق API؟
عادةً لا: فالعمليات الثقيلة مثل البحث أو الاستعلامات الجماعية مقيّدة بشدة أكبر من الفحص البسيط للحالة. والمرجع هو جدول الحدود لكل طريقة في الوثائق، لا رقم عام واحد.
القيم الدقيقة للحدود ورموز الأخطاء والترويسات الخاصة بالمهلة قبل إعادة المحاولة موجودة في وثائق OTP API.