أبرز المستجدات
انقر فوق أي request في Activity الآن وسترى الحمولة (payload) الكاملة. نقرة واحدة إضافية تفتحها مجددًا في Playground، معبأة مسبقًا وجاهزة لإعادة التشغيل. لقد رصدنا أيضًا فئة من خوادم "proxy" التي تعيد إرسال الـ request الخاص بك كـ response وهمي، ومنعناها من تلويث بياناتك.
ما الجديد
Activity ← Playground: إعادة تشغيل أي request
تأتي كل مكالمة API مصحوبة بـ header باسم X-Foura-Request-Id. يظهر المعرف نفسه بجوار الـ request في Activity. انقر فوق أي صف وستحصل على الصورة الكاملة: وقت التشغيل، والمفتاح المستخدم، وجسم الـ request، والـ response، ورموز الحالة (status codes)، والوقت المستغرق. انقر فوق "Open in Playground" ليتم تحميل الـ request في النموذج معبأً مسبقًا.
كانت إعادة التشغيل تعني سابقًا إعادة بناء الـ request من الذاكرة. أما الآن، يحتفظ Activity بالسجل، ويمثل Playground زر إعادة التشغيل.
بعض التفاصيل التقنية التي يجب معرفتها. نحتفظ بآخر 200 payload لكل مفتاح API لمدة 24 ساعة. بعد ذلك، تُحذف الإدخالات القديمة مع دخول إدخالات جديدة. عندما تنتهي صلاحية الـ payload، يخبرك مربع الحوار بذلك، بدلًا من عرض null أو "(empty body)" بشكل محير كما كان يحدث سابقًا.
معرف request يمكنك ربطه أيضًا. قم بتسجيل الـ response header المسمى X-Foura-Request-Id بجوار معرف الـ request الخاص بك في جانب العميل (client side)، ولن يتطلب العثور على صف Activity المطابق لاحقًا سوى عملية لصق واحدة.
تتم عملية الالتقاط خارج المسار الحرج (hot path). لا ينتظر الـ API request الخاص بك هذه العملية أبدًا. وإذا تعذر الوصول إلى مخزن الالتقاط، فستستمر المكالمة بنجاح، وسيعرض مربع الحوار ببساطة "no body captured" لاحقًا.
التحقق من الصحة استنادًا إلى الـ response body
حصل قسم Validate في Playground على قواعد لمحتوى الجسم (body-content). يمكنك تحديد "النجاح فقط إذا كان الـ response يحتوي على X"، أو "الفشل إذا كان يحتوي على Y"، مع إمكانية الفصل بين الخيارات المتعددة باستخدام |. تعمل هذه الميزة مع Single و Proxy. وهي مفيدة عندما تضلل رموز الحالة (status codes) بشأن ما حدث بالفعل.
الحمولات الخالية من الجسم توضح حالتها
الطلبات الفاشلة لا تحتوي على response body لعرضه. كان مربع الحوار القديم يعرض ذلك كـ null أو "(empty body)"، وهو ما كان يسهل فهمه بشكل خاطئ كـ response فارغ حقيقي. يميز مربع الحوار الآن بين ثلاث حالات: فشل الـ request (مع عرض رسالة الخطأ الفعلية)، أو عدم التقاط أي payload، أو أن الخادم أرجع بالفعل صفر بايت.
أمر بسيط، لكنه يزيل التساؤل المتكرر: "مهلًا، هل كان هذا هو الـ response أم خلل في واجهة المستخدم؟".
زر إعادة التعيين في Playground
يعيد نموذج الـ endpoint النشط إلى الإعدادات الافتراضية بنقرة واحدة. تحافظ الإعدادات الافتراضية على تفعيل unblocker و tryJsonData، حيث يمثل ذلك 90% من حالات الاستخدام.
خلف الكواليس
كشف خوادم proxy المخادعة (Honeypot)
بعض خوادم "proxy" المتاحة لا تقوم بالتوجيه فعليًا. بل تعيد إرسال الـ request الخاص بك كنسخة نصية من متغيرات الخادم (مثل HTTP method و headers و target host) حتى يتمكن المشغل من جمع أي بيانات تحتوي عليها. لقد رأينا نفس الـ proxy يوجه طلبًا واحدًا، ويعيد إرسال الطلب التالي، ويعطي خطأ 502 في الطلب الذي يليه، كل ذلك ضمن جلسة واحدة.
يقوم مدقق الجسم (body validator) الآن برصد توقيع هذه النسخة قبل أن يغادر الـ response حافتنا (edge). يعيد Single فشلًا صريحًا. ويعيد Proxy Finder المحاولة باستخدام proxy آخر. ويرث Browser نفس الحماية من طبقة HTTP المشتركة. وبذلك، سترى عددًا أقل من الصفوف غير المفيدة في Activity، ولن تقوم أدوات الكشط (scrapers) الخاصة بك بجمع بيانات تبدو حقيقية ولكنها في الواقع مجرد فحص (probe).
لا يوجد تغيير في السمعة (reputation) بعد. يظل الـ proxy في المجموعة حاليًا. نحن نرفض فقط تمرير كذبته إليك.
لذا: إذا ظهر request في Activity مصنفًا كفشل صريح بعد أن كان يظهر سابقًا كـ "نجاح" وهمي، فهذا يعني أن نظام الحماية قد رصده. الفشل الواضح أفضل من سجل ملوث بالبيانات الخاطئة.