كل المقالات

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

تدعم API في FourA الآن حدود إعادة توجيه قابلة للضبط واستجابات ثنائية خام. خياران يغيران طريقة تعاملك مع حالات حافة الكشط في العالم الحقيقي.

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

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

كيف يعمل ذلك

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

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

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

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 التتبع قبل الوصول إلى صفحة المنتج. وتريد متابعة ذلك. لكن شبكات التسويق بالعمولة ومختصرات URL تنشئ أحيانا سلاسل تصل إلى ست أو سبع أو ثماني قفزات. وبعض حلقات إعادة التوجيه لا تحل أبدا. وضع حد لعدد محدد يعني أنك تجمع البيانات دون أن تعلق في حلقة لا نهائية تستهلك مهلة الطلب.

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

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

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

يخبر 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
  }'

يعود جسم الاستجابة كبايتات خام (مشفرة بتنسيق base64 في استجابات JSON). قم بفك تشفيرها من جانبك وستحصل بالضبط على ما أرسله الخادم. لا افتراضات لمجموعة الأحرف، لا تحويل للتشفير، لا تلف صامت.

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

التأثير

تقلل كلتا الميزتين عدد مكالمات API لكل وظيفة. يزيل followRedirects حلقات تتبع إعادة التوجيه اليدوية. يزيل returnBuffer دورة "اجلب، أدرك أنه تالف، أعد الجلب بإعدادات مختلفة".

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

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

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

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

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 أو جدار رفض الوصول، فسيفشل الطلب بشكل نظيف. لا بيانات غير صالحة للتصفية لاحقا.

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

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

ماذا بعد

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

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