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

ما الجديد

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

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

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

كيف يعمل

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

الدرجات بالترتيب:

1. Cached session. إذا كان لدى Auto جلسة نشطة لهذا المضيف من نداء سابق، فإنه يعيد التشغيل من خلالها أولاً. هذا هو المسار الأرخص.
2. Proxy Finder. عبارة عن proxy request متناوب. جيد للمواقع المحمية بشكل أساسي من خلال سمعة عنوان IP.
3. Browser. تصيير (render) كامل ينفذ JavaScript، ويحل تحديات برامج الروبوت، ويجمع الـ cookies التي يصدرها الموقع.

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

نداء بسيط:

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

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 بتكلفة 2 من الأرصدة. لذا فإن الاستدعاء الثاني أرخص بـ 5 مرات من الأول، وكل استدعاء يليه يستمر في دفع السعر الرخيص طالما أن الجلسة مستمرة. لقد قسنا هذا في بيئة الإنتاج أثناء الإطلاق: تُعاد عمليات الخروج بدون ملفات تعريف الارتباط (بمجرد العثور عليها) بتكلفة 2 من الأرصدة لكل استدعاء مقابل 10 أرصدة كانت تكلفها عندما كان كل request يمر عبر Proxy Finder.

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

هذه هي القيمة الأساسية. تعمل الدرجة باهظة الثمن مرة واحدة، وتعمل الدرجة الرخيصة إلى الأبد بعد ذلك، ولا تضطر إلى كتابة منطق التخزين المؤقت (caching) بنفسك.

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

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

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

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

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

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

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

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

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

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

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"Authorization": "Bearer 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 نفسه، راجع الشرح التفصيلي السابق في قواعد التحقق تحدد الآن ما يعتبر نجاحا.

ماذا بعد

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

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

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

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