سلاسل إعادة التوجيه (Redirect chains) تؤدي إلى تعطل أدوات الكشط (scrapers). وتتعرض الاستجابات الثنائية (Binary responses) للتلف عند فك ترميزها كنص. مشكلتان تظهران باستمرار بمجرد تجاوزك لمرحلة "جلب الصفحة، وتحليل الـ HTML".
لقد أطلقنا خيارين جديدين للـ request للتعامل مع كلتا المشكلتين: followRedirects و returnBuffer. وهما متاحان الآن على الـ API.
كيف يعمل الأمر
التحكم في إعادة التوجيه باستخدام followRedirects
تتعامل معظم الـ APIs الخاصة بالكشط مع عمليات إعادة التوجيه كقيمة منطقية (boolean): إما تتبعها أو لا تفعل. يعمل هذا بشكل جيد إلى أن تواجه سلسلة إعادة توجيه حلقية (loop)، أو عندما تحتاج إلى استجابة 302 الوسيطة نفسها لاستخراج معلمة تتبع (tracking parameter).
يستقبل followRedirects الخاص بـ FourA عددًا صحيحًا بين 0 و 20. عند حذفه (أو تعيينه إلى 0)، ستحصل على استجابة إعادة التوجيه الخام، بما في ذلك الـ headers وكل شيء. وإذا قمت بتعيينه إلى 5، فسيتبع الـ request ما يصل إلى خمس قفزات (hops) قبل إرجاع الصفحة التي يستقر عليها في النهاية.
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/short-link",
"followRedirects": 3,
"unblocker": true
}'
يتبع هذا ما يصل إلى ثلاث عمليات إعادة توجيه. إذا انتهت السلسلة في خطوتين، فستحصل على الصفحة النهائية. وإذا كانت أطول من ثلاث، فستحصل على ما أرجعته القفزة الثالثة.
هذا الاختلاف يهم أكثر مما تعتقد. تقوم مواقع التجارة الإلكترونية بإعادة التوجيه عبر URLs للتتبع قبل الهبوط على صفحة المنتج. وتريد أنت تتبع هذه الروابط. ولكن شبكات التسويق بالعمولة (affiliate networks) ومواقع تقصير الـ URLs تنشئ أحيانًا سلاسل تصل إلى عمق ست أو سبع أو ثماني قفزات. وبعض حلقات إعادة التوجيه لا تنتهي أبدًا. يعني وضع حد أقصى عند رقم معين أنك تجمع البيانات دون أن تعلق في حلقة مفرغة تستهلك مهلة الـ request (request timeout) الخاصة بك.
قبل هذا، كان الحل البديل هو إرسال request مع تعطيل عمليات إعادة التوجيه، وتحليل الـ Location header يدويًا، ثم إرسال request آخر. يتطلب ذلك مكالمتي API كحد أدنى، وضعف زمن الاستجابة (latency)، وكودًا إضافيًا يتعين عليك صيانته. أما الآن، فالأمر يتطلب مكالمة واحدة مع تحديد رقم فقط.
الاستجابات الثنائية الخام باستخدام returnBuffer
عندما تقوم بجمع الصور، أو ملفات PDF، أو حمولات protobuf، فإن فك ترميز النصوص يؤدي إلى تدمير البيانات. تفترض مكتبة HTTP أن الاستجابة هي نص، وتطبق كشف ترميز الأحرف (charset detection)، وتتلف بصمت كل بايت لا يتوافق مع ذلك. يصبح Protobuf غير قابل للقراءة. وتتعطل الـ headers الخاصة بالصور. وينتهي بك الأمر بملفات تالفة ودون أي رسالة خطأ واضحة تشرح السبب.
يخبر returnBuffer الـ API بتخطي فك ترميز النصوص تمامًا.
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/product-image.jpg",
"returnBuffer": true
}'
يأتي جسم الاستجابة (response body) كبايتات خام (مُرمزة بصيغة base64 في استجابات JSON). قم بفك ترميزها من جانبك وستحصل على ما أرسله الخادم تمامًا. لا افتراضات لترميز الأحرف، ولا تحويل للترميز، ولا تلف صامت للبيانات.
كانت هذه واحدة من أكثر تذاكر الدعم الفني شيوعًا التي تلقيناها: مستخدمون يجمعون صور المنتجات أو كتالوجات PDF ويحصلون على ملفات لا تفتح. كان الحل دائمًا هو نفسه، ولكن الآن أصبح هناك خيار (flag) مخصص لذلك بدلاً من استخدام حل بديل.
الأثر
يقلل كلا الخيارين من عدد مكالمات الـ API لكل مهمة. يلغي followRedirects حلقات تتبع إعادة التوجيه اليدوية. ويلغي returnBuffer دورة "الجلب، ثم إدراك التلف، ثم إعادة الجلب بإعدادات مختلفة".
بالنسبة للأهداف التي تعتمد بكثافة على إعادة التوجيه (روابط التسويق بالعمولة، ومواقع تقصير الـ URLs، وسلاسل تتبع التجارة الإلكترونية)، لاحظنا انخفاضًا في عدد الـ requests بنسبة تتراوح بين 40% إلى 60% في الاختبارات الأولية عندما ينتقل المستخدمون من المعالجة اليدوية لإعادة التوجيه إلى followRedirects. وبالنسبة لمهام جمع الملفات الثنائية (صور المنتجات، وتنزيل المستندات)، يحول returnBuffer الحل البديل متعدد الخطوات إلى خيار واحد (النتائج الأولية).
هذه ليست ميزات استعراضية. إنها من نوعية الأشياء التي لا تفكر فيها حتى يتعطل مِكشطك (scraper) في الساعة 3 صباحًا لأن أحد المواقع أضاف قفزة إعادة توجيه إضافية إلى مسار الدفع الخاص به.
للمستخدمين المتقدمين
اجمع بين followRedirects والتحقق من الاستجابة (response validation) للتحكم الدقيق في سلاسل إعادة التوجيه. تتبع عمليات إعادة التوجيه، ولكن اجعل الـ request يفشل إذا واجهت الوجهة النهائية جدار حظر:
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "Authorization: Bearer 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"] }
}
}'
يتبع هذا ما يصل إلى خمس عمليات إعادة توجيه، ثم يتحقق من الاستجابة النهائية. إذا أعاد الموقع توجيهك إلى صفحة CAPTCHA أو جدار حظر الوصول (access-denied)، فإن الـ request يفشل بشكل نظيف. لا توجد بيانات تالفة لتصفيتها لاحقًا في مرحلة المعالجة.
لجمع الملفات الثنائية، اربط returnBuffer بـ requests من نوع HEAD عندما تحتاج إلى التحقق من أنواع المحتوى (content types) قبل تنزيل الملفات الكبيرة. تتعامل FourA مع HEAD بشكل صحيح (مما يمنع أخطاء libcurl الشائعة داخليًا)، بحيث يمكنك فحص الـ headers دون جلب الـ body. تحقق من الـ Content-Type، وقرر ما إذا كان الأمر يستحق التنزيل، ثم أرسل الـ request الكامل مع returnBuffer: true.
وإذا كنت تستخدم مهام المتصفح للأهداف التي تعتمد بكثافة على JavaScript، فلاحظ أن هذه الخيارات تنطبق على محرك HTTP المباشر. تتعامل requests المتصفح مع عمليات إعادة التوجيه من خلال نظام التنقل المدمج في Chrome، والذي يتبعها افتراضيًا دون حد أقصى.
الخطوات القادمة
نحن نعمل على توفير المزيد من عناصر التحكم على مستوى الـ request عبر الـ API: حل DNS مخصص (custom DNS resolution)، وضبط المهلة لكل مرحلة (per-phase timeout tuning)، وخيارات معالجة الشهادات (certificate handling). الهدف هو توفير القوة الكاملة لـ curl-impersonate من خلال واجهة REST نظيفة، دون أعباء البنية التحتية الإضافية.
إذا كان هناك خيار محدد تحتاجه، فنحن نستمع إليك. تعرض لوحة التحكم بالفعل كيفية أداء الـ requests الخاصة بك مع هذه الخيارات الجديدة، بحيث يمكنك قياس الفرق بنفسك.