التحكم في إعادة التوجيه ووضع المخزن المؤقت الخام

تتسبب سلاسل إعادة التوجيه في تعطل أدوات الكشط. وتتلف الاستجابات الثنائية عند فك ترميزها كنص. هاتان مشكلتان تتكرران باستمرار بمجرد تجاوز مرحلة "جلب صفحة وتحليل الـ HTML".

أطلقنا خيارين جديدين للـ request للتعامل مع كلتا الحالتين: followRedirects و returnBuffer. الخياران متاحان الآن على الـ API.

آلية العمل

التحكم في إعادة التوجيه باستخدام followRedirects

تتعامل معظم واجهات برمجة التطبيقات للكشط مع عمليات إعادة التوجيه كقيمة منطقية (boolean): إما تتبعها أو تجاهلها. ينجح هذا الأسلوب حتى تصطدم بسلسلة إعادة توجيه حلقية، أو عندما تحتاج إلى استجابة 302 الوسيطة نفسها لاستخراج معامل تتبع.

يقبل خيار followRedirects في FourA عددا صحيحا بين 0 و 20. عند حذفه (أو ضبطه على 0)، ستحصل على استجابة إعادة التوجيه الأولية كاملة مع الـ headers. اضبطه على 5، وسيتبع الـ request ما يصل إلى 5 قفزات قبل إرجاع الوجهة النهائية التي يصل إليها.

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/short-link",
    "followRedirects": 3,
    "unblocker": true
  }'

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

هذا الفارق أكثر أهمية مما تعتقد. تعيد مواقع التجارة الإلكترونية التوجيه عبر عناوين URL للتتبع قبل الوصول إلى صفحة المنتج. وترغب أنت في تتبعها. لكن شبكات التسويق بالعمولة وخدمات تقصير عناوين URL تنشئ أحيانا سلاسل تصل إلى ست أو سبع أو ثماني قفزات. وبعض حلقات إعادة التوجيه لا تنتهي أبدا. تحديد سقف برقم معين يعني أنك تجمع البيانات دون أن تعلق في حلقة لا نهائية تستهلك مهلة الـ request بالكامل.

قبل ذلك، كان الحل البديل هو إرسال request مع تعطيل عمليات إعادة التوجيه، وتحليل الـ header الخاص بـ Location يدويا، ثم إرسال request آخر. يتطلب ذلك عمليتي استدعاء API كحد أدنى، وضعف زمن الاستجابة، وكودا برمجيا يتعين عليك صيانته. أما الآن فهو استدعاء واحد يتضمن رقما.

استجابات ثنائية خام باستخدام returnBuffer

عندما تجمع الصور، أو ملفات PDF، أو حمولات protobuf، فإن فك ترميز النصوص يتلف البيانات. تفترض مكتبة HTTP أن الاستجابة عبارة عن نص، وتطبق اكتشاف مجموعة الأحرف، وتشوه بصمت كل بايت لا يتطابق معها. يصبح الـ protobuf غير قابل للقراءة، وتتعطل ترويسات الصور. وينتهي بك الأمر بملفات تالفة ودون أي رسالة خطأ واضحة لتفسير السبب.

يطلب returnBuffer من الـ API تخطي فك ترميز النصوص تماما.

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/product-image.jpg",
    "returnBuffer": true
  }'

يصل response body كبايتات خام (base64-encoded في استجابات JSON). فك ترميزه من جانبك لتحصل على ما أرسله الخادم تماما. لا افتراضات حول charset، ولا تحويل للترميز، ولا تلف صامت للبيانات.

كانت هذه إحدى تذاكر الدعم الأكثر شيوعا لدينا: مستخدمون يجمعون صور منتجات أو ملفات PDF وتصلهم ملفات لا تفتح. كان الحل ثابتا دائما، ولكن يوجد الآن flag مخصص لذلك بدلا من استخدام حلول بديلة.

الأثر

تقلل الميزتان عدد استدعاءات API لكل مهمة. تنهي followRedirects حلقات تتبع إعادة التوجيه اليدوية. وتنهي returnBuffer حلقة "الجلب، ثم اكتشاف تلف الملف، ثم إعادة الجلب بإعدادات مختلفة".

بالنسبة للأهداف كثيفة عمليات إعادة التوجيه (روابط التسويق بالعمولة، ومختصرات URL، وسلاسل تتبع التجارة الإلكترونية)، شهدنا انخفاضا في عدد requests بنسبة 40-60% في الاختبارات الأولية عندما انتقل المستخدمون من المعالجة اليدوية لإعادة التوجيه إلى followRedirects. وبالنسبة لمهام جمع الملفات الثنائية (صور المنتجات، وتنزيل المستندات)، تحول returnBuffer الحل البديل متعدد الخطوات إلى خيار واحد (نتائج أولية).

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

للمستخدمين المتقدمين

اجمع بين followRedirects والتحقق من الاستجابة لتحكم دقيق في سلاسل إعادة التوجيه. تتبع عمليات إعادة التوجيه، ولكن أوقف الـ request إذا وصلت الوجهة النهائية إلى حائط مسدود:

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/product/12345",
    "followRedirects": 5,
    "unblocker": true,
    "validate": {
      "status": { "fail": [403, 503] },
      "data": { "fail": ["Access Denied", "captcha"] }
    }
  }'

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

لجمع الملفات الثنائية (binary)، ادمج returnBuffer مع طلبات HEAD عندما تحتاج إلى التحقق من أنواع المحتوى قبل تنزيل الملفات الكبيرة. يتعامل FourA مع HEAD بشكل صحيح، مما يتيح لك فحص الترويسات (headers) دون جلب متن الطلب. تحقق من Content-Type، وحدد ما إذا كان يستحق التنزيل، ثم نفذ الطلب الكامل باستخدام returnBuffer: true.

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

ما التالي

نحن نعمل على توفير المزيد من عناصر التحكم على مستوى الطلب عبر API: دقة DNS مخصصة، وضبط المهلة لكل مرحلة، وخيارات معالجة الشهادات. الهدف هو التحكم الكامل في ملف تعريف المتصفح عبر واجهة REST نظيفة، ودون أعباء البنية التحتية.

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