لوحة تكشف استهلاك API قبل نفاد الرصيد: مشروع تخرج هندسة البرمجيات

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

أنشئ أحداثاً بلا أسرار

اجعل كل سجل يحتوي وقتاً اصطناعياً ومساراً عاماً ورمز استجابة وحجماً وعدداً افتراضياً من وحدات التكلفة. لا تخزن Authorization header أو محتوى المستخدم أو مفتاح خدمة. يولد البرنامج البيانات ببذرة ثابتة، أو يقرأ ملف CSV من المطور. سم الوحدات «نقاط سيناريو» لا دولارات، ما لم تدخل سعراً مؤرخاً من مصدر رسمي. افصل خطة الاستخدام عن سجل الأحداث: حد لكل دقيقة ونافذة يومية وعتبة تنبيه يحددها المستخدم، كي يستطيع إعادة تشغيل المثال من غير اعتماد على مزود حقيقي.

تعرف RFC 6585 الحالة 429 لمعنى الطلبات الكثيرة خلال فترة معينة، وتتيح تضمين Retry-After. وتعرض RFC 9110 دلالات HTTP لذلك الحقل. المعياران لا يحددان حصصاً أو أسعاراً لمزود بعينه. إذا لم يوجد الحقل، فلا تخترع وقت انتظار رسمي؛ اعرض أن السيناريو لا يملك قيمة واختبر سياسة محلية مقترحة بوصفها اختياراً تعليمياً.

احسب الحصة في نافذة معلنة

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

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

مثال ثلاث شاشات دون استدعاء حي

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

عند وجود Retry-After في الاستجابة الوهمية، اعرض وقت التأجيل الذي يطلبه المثال، ثم حد إعادة المحاولة الكلي. إذا كان الحقل مفقوداً أو قيمته غير صالحة، يستخدم المحاكي سياسة بديلة يختارها المستخدم مع تسمية واضحة. لا ترسل أي طلب للشبكة عند الضغط على «إعادة». محتوى الصفحة يجب أن يوضح أن كل محاولة حدث محلي. المثال يقيس سلوك عداد ومهلة اصطناعية، وليس أداء خادوم أو صحة مزود API في العالم الحقيقي.

صمم التنبيه ليذكر سببه

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

احذر من تجميع كل المسارات تحت مستخدم واحد أو وضع endpoint بالاسم الكامل إذا كان يحمل معرفاً حساساً. بيانات المحاكي اصطناعية في الإصدار الأول ولا تحتاج ملفات شخصية. احفظ إعدادات التنبيه محلياً، واسمح بتصدير تقرير لا يحتوي أسراراً. عندما تتغير خطة الاختبار، أنشئ نسخة جديدة من config كي يكون الفرق بين النتائج قابلاً للفهم، واحتفظ بالتقرير الأول كما هو بدلاً من تحديث الأرقام في مكانها.

اختبر الحد والوقت والفشل

اكتب حالات صفر أحداث، الحد تماماً، طلب فوق الحد، نافذة تدور عبر منتصف الليل، حقل Retry-After غير موجود، قيمة سالبة، وإعادة محاولات تصل إلى السقف. قارن كل عداد بعملية يدوية واستخدم بذرة ثابتة لإعادة النتيجة. اختبر توقيتاً متساوياً للحدثين وحدد ترتيب المعالجة. يجب ألا تستمر الحلقة إلى ما لا نهاية عند timeout، وألا يضيع الحدث الذي يتزامن مع انتهاء النافذة. افحص أن الطلب لا يخرج من الجهاز ولا توجد خانة لإدخال مفتاح API في الواجهة.

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

مختبر مراقبة لا يربط حساباً مدفوعاً

تشمل النسخة الأولى مولد سيناريو وسجل أحداث ومحرك نافذة ولوحة عتبات وتصدير CSV ومجموعة اختبارات. يستطيع الفريق شرح الفرق بين عداد يومي ونافذة محددة، وكيف يتصرف التطبيق مع 429. لا يحتاج إلى مفتاح أو اشتراك API، ولا يتطلب وضع بيانات عميل في مستودع التخرج. يظل تمييز الاختبارات عن القياس الفعلي أساس التقرير؛ أي سطر يصف نتيجة مستقبلية يجب أن يذكر أنها فرضية تحتاج تشغيل وقياساً.

يرتبط العمل بـتشخيص أخطاء API لكنه يركز على تدفق الحصة وإعادة المحاولة الافتراضية لا تحليل علة استجابة منفردة. يمكن لطالب مشاريع تخرج هندسة البرمجيات استخدام توثيق OpenAPI لتسمية المسارات، مع التصريح أن الخطة اصطناعية. لا تستنتج سعراً أو سياسة مزود من status code وحده؛ قبل تكامل حقيقي راجع شروط الخدمة ومصدر quota المؤرخ.