Rate Limiting
تحديد المعدل (Rate Limiting) هو آلية حماية تقيّد عدد طلبات API ضمن نافذة زمنية محددة، لضمان الاستخدام العادل والحفاظ على استقرار النظام. عند تجاوز الحد، تحصل على استجابة HTTP 429 مع ترويسة Retry-After.
ما هو تحديد المعدل؟
تحديد المعدل (Rate Limiting) آلية للتحكم في حركة المرور تضبط عدد طلبات API التي يمكن لعميل واحد (يُعرَّف بمفتاح API أو عنوان IP) إرسالها ضمن نافذة زمنية محددة – مثلاً 100 طلب في الدقيقة أو 10,000 رسالة في اليوم. تحمي هذه الحدود البنية التحتية للواجهة من التحميل الزائد وتضمن وصولاً متكافئاً لجميع العملاء. فبدون تحديد المعدل، قد يُطلِق روبوت واحد معطوب آلاف الطلبات في الثانية ويُبطئ الخدمة على الجميع.
تقنياً، يُنفَّذ تحديد المعدل غالباً عبر خوارزميات Token Bucket أو Sliding Window. لكل مفتاح API "رصيد" من الطلبات يتجدد باستمرار. مع كل طلب تُرسله يُستهلَك رمز (token). وعند نفاد جميع الرموز، عليك الانتظار حتى يُعاد ملؤها. تستخدم SendSeven نظاماً عادلاً وشفافاً برسائل خطأ واضحة وإرشادات لإعادة المحاولة.
لماذا تُوجد حدود المعدل؟
استقرار النظام: تتشارك الواجهات الموارد (المعالج، قاعدة البيانات، الشبكة). قد يُعطّل عميل "سيّئ" واحد النظام بأكمله دون حدود – ويمنع تحديد المعدل مثل هذه السيناريوهات من نوع حجب الخدمة.
الاستخدام العادل: ينبغي أن يستفيد جميع العملاء بالتساوي. فإذا استهلك عميل واحد 90% من السعة، تضرّر الآخرون. تضمن حدود المعدل الإنصاف.
التحكم في التكلفة: قد تُطلق الحلقات اللانهائية العَرَضية في شيفرتك ملايين الطلبات دون حدود – وتُسبّب تكاليف مقابلة. يعمل تحديد المعدل كمكبح طوارئ.
الحماية من إساءة الاستخدام: غالباً ما يحاول مرسلو الرسائل المزعجة والمهاجمون إغراق الواجهات. تجعل حدود المعدل هذه الهجمات غير مجدية اقتصادياً وقابلة للكشف.
التعامل مع استجابات HTTP 429
عند تجاوز حد المعدل، تردّ الواجهة بالرمز HTTP 429 (Too Many Requests). تحتوي ترويسة الاستجابة على معلومات مهمة:
HTTP/1.1 429 Too Many Requests Retry-After: 60 X-RateLimit-Limit: 100 X-RateLimit-Remaining: 0 X-RateLimit-Reset: 1676543210
Retry-After: عدد الثواني التي يجب الانتظار قبل السماح بالطلب التالي.
X-RateLimit-Limit: حدك الإجمالي (مثلاً 100 طلب في الدقيقة).
X-RateLimit-Remaining: عدد الطلبات المتبقية المتاحة (هنا: 0).
X-RateLimit-Reset: طابع زمني Unix لموعد إعادة ضبط الحد.
تُطبّق التطبيقات الاحترافية التراجع الأسّي (Exponential Backoff): بعد خطأ 429، لا تنتظر 60 ثانية ثابتة فحسب، بل تُضاعف مدة الانتظار مع كل خطأ إضافي (1 ثانية، 2، 4، 8، ...). يمنع ذلك مشكلات "اندفاع القطيع" (Thundering Herd) حيث يُعيد آلاف العملاء المحاولة في وقت واحد فيُحمّلون النظام من جديد.
حدود المعدل في SendSeven
تطبّق SendSeven حدود المعدل لكل مساحة عمل، وليس لكل مفتاح API؛ أما نقاط نهاية تسجيل الدخول والمصادقة فتُحتسب لكل عنوان IP. يُقاس كل حد ضمن نافذة متحركة مدتها 60 ثانية، ويتقاسم تكاملك هذه الحصة مع لوحة التحكم. الحدود نفسها في جميع الباقات. تتضمن كل استجابة الترويسات X-RateLimit-Limit وX-RateLimit-Remaining وX-RateLimit-Reset، فيعرف تطبيقك وضعه في كل لحظة. وعند تجاوز حد ما، تُرجع الواجهة استجابة 429 مع ترويسة Retry-After تحدد عدد الثواني التي ينبغي انتظارها.
للإرسال الجماعي، ننصح باستخدام ميزة Reach (الحملات) المدمجة في SendSeven بدلاً من استدعاءات API الفردية. تُعالَج الحملات على الخادم: تحدد أنت سرعة الإرسال وحجم الدفعات، وفي WhatsApp يمكنك توزيع الإرسال الكبير على عدة أيام لحماية رقم جديد. ولا حاجة لأن تدير حدود المعدل بنفسك.
تجد القيم الحالية في توثيق الواجهة على docs.sendseven.com. أفضل ممارسة: راقب X-RateLimit-Remaining، وخفّف الوتيرة قبل أن تصل إلى الصفر، وضع الطلبات في قائمة انتظار من جانب العميل حتى لا يصل خطأ 429 إلى مستخدميك أبداً.