← Всички публикации
Продуктово обновление 6 мин. четене

Представяме Auto: Един endpoint за всяка цел

Auto endpoint избира Single, Proxy Finder или Browser за всеки request, обработва anti-bot защитите и връща сесия, която следващото ви извикване може да преизползва.

autoapiorchestrationsessionsanti-bot

Какво ново

/api/auto endpoint вече е най-краткият път до работещ response за всеки URL. Насочете го към целта. Auto избира дали да изпълни заявката през Single, Proxy Finder или Browser, справя се с anti-bot защитите при среща с такива и връща сесия, която следващото ви извикване може да преизползва.

Един endpoint. Всяка цел. Без превключване на режими от ваша страна.

Това е цялата идея. Останалата част от публикацията обяснява как работи, колко струва и какви са спецификите.

Как работи

Auto използва йерархия от стъпки (първо евтините, накрая скъпите). При всяка заявка Auto минава през стъпките, докато някоя от тях не върне response, който вашите validate правила приемат.

Стъпките, по ред:

  1. Кеширана сесия. Ако Auto има активна сесия за този хост от предишно извикване, първо опитва през нея. Най-евтиният път.
  2. Proxy Finder. Заявка с ротирано proxy. Подходящо за сайтове, защитени главно чрез IP репутация.
  3. Browser. Пълно рендиране, което изпълнява JavaScript, решава anti-bot предизвикателства и събира бисквитките, издадени от сайта.

Щом дадена стъпка успее, Auto запазва намерената сесия: използваното proxy id, издадените cookies и User-Agent. При следващото извикване към същия хост Auto първо пробва тази сесия. Ако тя все още работи, плащате за евтината стъпка, а не за скъпата.

Минимално извикване:

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] } }
  }'

Съкратен 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: рендериране, решаване, събиране на бисквитки, връщане на страницата. Това струва около 10 кредита. След като Auto кешира работеща сесия за този хост, следващите извиквания я преизползват: чрез Single на цена от 2 кредита или чрез Proxy Finder на 4, когато бисквитките на сесията работят от всеки адрес. Така второто извикване е до 5 пъти по-евтино от първото, а всяко следващо запазва ниската цена, докато сесията е валидна. Измерихме това в продукционна среда по време на внедряването: изходите без бисквитки (след като бъдат намерени) се възпроизвеждат точно на 2 кредита за извикване спрямо 10, които струваха преди, когато всяка заявка минаваше през Proxy Finder.

Второто число: неуспешните нива не се таксуват. Ако Auto опита три проксита и всяко върне статус 403, преди четвъртото да достави резултат, се отчитат само кредитите за четвъртото. Плащате за доставено съдържание, а не за търсенето.

Това е основната полза. Скъпото ниво се изпълнява веднъж, евтиното ниво работи оттам нататък и не се налага да пишете логиката за кеширане сами.

Струва си да се отбележат още две поведения, тъй като те решават реални главоболия в продукция:

Целите с гео-ограничения спират да хабят изходи. Когато даден сайт връща 451 (или междинна страница за правно блокиране) за повечето изходи, Auto научава кои държави реално са доставили съдържание. При следващото извикване то извлича нови изходи първо от тези държави и разпределя паралелното натоварване между тях. Така един късметлийски изход не се претоварва и не попада под rate limit ограничения.

Валидацията се изпълнява на всяко ниво. Страница с грешно съдържание (гео-блок, който връща статус 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 е клиентски avoid-list. Подайте proxy id-та, за които знаете, че са компрометирани (от предишна session.proxy, която е получила rate limit от ваша страна), и Auto ще ги прескача навсякъде: при повторно използване на warm сесии, търсене на exit точки и под-заявки към Proxy Finder. Така Auto няма да избере отново същия exit, който току-що сте посочили да се избягва.

meta ви позволява също да изградите собствени табла за управление: кои хостове са достигнали браузърното ниво днес, среден брой опити за доставка, съотношение на заявките с решен challenge към чистите такива. Ако даден хост внезапно скочи от 2 на 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.

Какво следва

В момента в roadmap за Auto има две неща.

Инспекцията на сесиите идва след това в Dashboard. В момента сесиите, които Auto поддържа за всеки хост, се намират вътре в услугата и няма какво да прегледате, когато дебъгвате прекомерно изразходване от ваша страна. Изграждаме изглед на сесиите по хостове, за да можете да виждате кешираните сесии, тяхната възраст, колко време ще останат активни и историята на нивата (rung) зад всяка една. Плюс бутон за ръчно премахване на сесия, когато целта ви се промени и знаете, че кешът е невалиден.

След това, по-стриктен контрол върху разходите. Твърд лимит на кредитите за заявка (никога не харчи повече от X за това извикване, върни честна грешка, ако се налага) и режим "single-only" за екипи, чиито цели никога нямат нужда от browser нивото. И двете функционалности в момента са зад флагове.

Смисълът на Auto е да не мислите кой продукт да извикате. Това не означава, че не можете да проверите какво се е случило. Всеки response връща използваното ниво и сесията, която е изградил. Прочетете тези две полета и ще знаете точно защо вашите извиквания струват толкова, колкото струват.