تقديم Auto: endpoint واحد لأي هدف

ما الجديد

أصبح endpoint الخاص بـ /api/auto الآن أقصر مسار للحصول على response صالح لأي URL. وجّهه نحو الهدف. يحدد Auto تلقائياً ما إذا كان سيشغل request عبر Single أو Proxy Finder أو Browser، ويتعامل مع تحديات anti-bot عند مواجهتها، ثم يعيد session يمكنك إعادة استخدامها في استدعائك التالي.

endpoint واحد. أي هدف. دون الحاجة إلى التبديل بين الأوضاع من جانبك.

هذه هي الفكرة بالكامل. بقية هذا المقال تشرح آلية عمله، وتكلفته، وأبرز النقاط الدقيقة التي يجب الانتباه إليها.

آلية العمل

يعتمد Auto على تدرج من المستويات (الأقل تكلفة أولاً، والأعلى تكلفة أخيراً). في كل request، يصعد Auto هذا التدرج حتى ينجح أحد المستويات في تقديم response تقبله قواعد validate الخاصة بك.

المستويات، بالترتيب:

Cached session. إذا كان لدى Auto جلسة نشطة لهذا المضيف من استدعاء سابق، فإنه يعيد تنفيذ الطلب من خلالها أولاً. هذا هو المسار الأقل تكلفة.
Proxy Finder. طلب عبر proxy مُدار دورياً. مناسب للمواقع المحمية أساساً عبر سمعة عناوين IP.
Browser. عملية render كاملة تُنفذ JavaScript، وتحل تحديات anti-bot، وتجمع cookies التي يصدرها الموقع.

بمجرد نجاح أحد المستويات، يخزن Auto الـ session التي عثر عليها: الـ proxy id المستخدم، وcookies التي أصدرها الموقع، وUser-Agent. في الاستدعاء التالي لنفس المضيف، يجرّب Auto هذه الـ session أولاً. إذا كانت لا تزال تعمل، فستدفع تكلفة المستوى الأرخص، وليس الأعلى.

استدعاء مبسط:

curl -X POST "https://api.foura.ai/api/auto" \
  -H "X-API-Key: pk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/data",
    "validate": { "status": { "accept": [200] } }
  }'

استجابة مقتطعة (trimmed response):

{
  "status": 200,
  "data": "...",
  "headers": [...],
  "meta": {
    "rung": "cache",
    "solved": false,
    "attempts": 1,
    "credits": 2
  },
  "session": {
    "proxy": "CLN1B8",
    "cookies": [{ "name": "cf_clearance", "value": "..." }],
    "userAgent": "..."
  }
}

حقلان مهمان لما ستبنيه لاحقا. يوضح لك meta.rung أي مسار كان الفائز. أما session فهو الثلاثية التي يمكنك تمريرها إلى استدعاء /api/single لإعادة استخدام نفس نقطة الخروج بنفسك. حقل proxy هو معرف base36 مبهم (لا يحتوي على عناوين IP أولية)، مما يجعله آمنا للتسجيل في السجلات وآمنا للتمرير بين الأنظمة.

التأثير

رقمان مهمان هنا.

الاستدعاء الأول لموقع محمي يشغل مستوى Browser: التصيير، والحل، وتجميع cookies، وتسليم الصفحة لك. يكلف ذلك نحو 10 أرصدة. بمجرد أن يقوم Auto بتخزين جلسة عمل مؤقتا لهذا المضيف، فإن الاستدعاءات اللاحقة تعيد تشغيلها: عبر Single بمقابل رصيدين، أو عبر Proxy Finder بمقابل 4 أرصدة عندما تعمل cookies الخاصة بالجلسة من أي عنوان. وبالتالي، يكون الاستدعاء الثاني أرخص بما يصل إلى 5 أضعاف مقارنة بالأول، ويستمر كل استدعاء بعده في دفع السعر المنخفض طالما بقيت الجلسة صالحة. لقد قمنا بقياس ذلك في بيئة الإنتاج أثناء الإطلاق: نقاط الخروج التي لا تتطلب cookie (بمجرد العثور عليها) يعاد تشغيلها برصيدين بالضبط لكل استدعاء مقارنة بالأرصدة العشرة التي كانت تكلفها سابقا عندما كان كل request يمر عبر Proxy Finder.

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

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

هناك سلوكان آخران يستحقان الإشارة إليهما لأنهما يحلان مشكلات حقيقية في بيئات الإنتاج:

الأهداف المقيدة جغرافيا تتوقف عن إهدار نقاط الخروج. عندما يعيد موقع ما رمز 451 (أو صفحة بينية للحجب القانوني) لمعظم نقاط الخروج، يتعلم Auto أي البلدان نجحت فعليا في تسليم المحتوى. وفي الاستدعاء التالي، يسحب نقاط خروج جديدة من تلك البلدان أولا ويوزع الحمل المتزامن عبرها. وبذلك لا يتم تكديس الطلبات على نقطة خروج ناجحة واحدة والوصول إلى rate limit.

يعمل Validate على كل مستوى. صفحة المحتوى الخاطئ (الحجب الجغرافي الذي يعيد كود الحالة 200 مع إشعار قانوني في المتن) لا تحسب أبدا كنتيجة ناجحة. إذا تضمن validate.data.fail عبارة "legal reasons"، يواصل Auto المحاولة حتى يجتاز مستوى ما الفحص. لا المستوى المخزن مؤقتا. ولا أي مستوى آخر. وإذا لم ينجح أي شيء، فستحصل على فشل صريح بالسبب الحقيقي.

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

بعض عناصر التحكم المهمة بمجرد زيادة حجم العمليات عبر Auto.

يمثل timeout_ms ميزانية للعملية بأكملها، وليس لكل مستوى على حدة. القيمة الافتراضية هي 120 ثانية. يقسمها Auto: يحصل كل استدعاء فرعي على الحد الأدنى بين (مهلة انتهاء صلاحيته الطبيعية، والميزانية المتبقية)، ويتوقف التدرج عن إطلاق مستويات جديدة بمجرد أن يتبقى القليل جدا من الوقت. اضبطه على 20,000 لعمليات زمن الاستجابة التفاعلي. واترك القيمة الافتراضية لعمليات الزحف الكبيرة التي تتحمل أوقاتا أطول.

يكون forceProxy مفعلا افتراضيا. لا يتصل Auto بالهدف أبدا من عنوان IP المصدر الخاص بـ FourA إلا إذا قمت بضبط forceProxy: false. تنبيه واحد: بعض المواقع (صفحات Cloudflare التفاعلية ذات التحقق المعتمد على موثوقية IP) تعمل في الواقع بشكل أفضل من IP مركز بيانات نظيف مقارنة بنقطة خروج سكنية منخفضة الموثوقية. لذلك يمكن لـ forceProxy: false أن يجعل الوصول إلى أهداف معينة أسهل، وليس أصعب. إذا كنت تواجه تحديات متكررة على مضيف معين، فإن تجربة تعطيل هذا الخيار تستحق المحاولة.

إن ignoreProxies عبارة عن قائمة حظر من جانب العميل. مرر معرفات proxy التي تعرف أنها محظورة (من session.proxy سابق تعرض لـ rate limit من جانبك)، وسيتخطاها Auto بالكامل: إعادة استخدام الجلسات الجاهزة (warm sessions)، والبحث عن نقاط الخروج، والاستدعاء الفرعي إلى Proxy Finder. وبالتالي لن يعيد Auto اختيار نقطة الخروج التي طلبت منه تجنبها للتو.

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

مثال يجمع بين العناصر الأربعة كلها:

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"X-API-Key": "pk_live_..."},
    json={
        "url": "https://example.com/product/9876",
        "timeout_ms": 30000,
        "forceProxy": True,
        "ignoreProxies": ["CLN1B8", "K7X9AB"],
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ['"price":'], "fail": ["captcha", "legal reasons"]}
        }
    }
).json()

# If Auto delivered, keep the session for the next call to this host
if r.get("status") == 200 and "session" in r:
    session = r["session"]                              # {proxy, cookies, userAgent}
    print(r["meta"]["rung"], r["meta"]["credits"], r["meta"]["attempts"])

بالنسبة لمخطط validate نفسه، راجع الشرح التفصيلي السابق في Validate Rules Now Decide What Counts as Success.

ما التالي

هناك أمران على خارطة طريق Auto حاليًا.

فحص الجلسات سيتوفر في Dashboard قريبًا. في الوقت الحالي، توجد الجلسات التي يحتفظ بها Auto لكل host داخل الخدمة، ولا يوجد ما يمكن الاطلاع عليه عند استكشاف أخطاء الاستهلاك من جانبك. نعمل على إعداد عرض للجلسات لكل host لتتمكن من رؤية الجلسات المخزنة مؤقتًا، وأعمارها، ومدة بقائها، وتاريخ rung المرتبط بكل منها. بالإضافة إلى زر لإسقاط الجلسة يدويًا عند تغير الهدف ومعرفتك بأن البيانات المخزنة مؤقتًا غير صحيحة.

بعد ذلك، تحكم أكثر دقة في التكاليف. حد أقصى صارم للرصيد لكل request (عدم إنفاق أكثر من X في هذا الاستدعاء، مع إرجاع فشل صريح إذا تطلب الأمر تجاوز ذلك)، ووضع "single-only" للفرق التي لا تتطلب أهدافها الوصول إلى rung الخاص بالمتصفح. كلا الخيارين متاحان خلف flags اليوم.

الهدف من Auto هو ألا تضطر للتفكير في أي منتج يجب استدعاؤه. هذا لا يعني أنه لا يمكنك فحص ما حدث. كل response يرسل rung الذي استُخدم والجلسة التي أنشأها. اقرأ هذين الحقلين وستعرف بدقة سبب تكلفة استدعاءاتك.