Какво ново
Ендпойнтът /api/auto вече е най-краткият път до работещ response за всяко URL. Насочете го към целта. Auto избира дали да изпълни заявката през Single, Proxy Finder или Browser, справя се с anti-bot защитите при нужда и връща сесия, която следващата ви заявка може да използва отново.
Един endpoint. Всяка цел. Без превключване на режими от ваша страна.
Това е цялата идея. Останалата част от този пост описва как работи, колко струва и къде са слабите места.
Как работи
Под Auto стои стълба от нива (първо евтините, после скъпите). При всяка заявка Auto се изкачва по стълбата, докато едно от нивата не върне response, който вашите validate правила приемат.
Нивата по ред:
- Cached session. Ако Auto има топла сесия за този хост от предишна заявка, първо повтаря през нея. Най-евтиният път.
- Proxy Finder. Заявка с ротиран proxy. Добре е за сайтове, защитени главно чрез IP репутация.
- Browser. Пълен рендер, който изпълнява JavaScript, решава anti-bot защити и събира cookie-тата, които сайтът издава.
Щом едно ниво спечели, Auto запазва намерената сесия: използваният proxy id, издадените от сайта cookie-та и 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: рендиране, решаване, събиране на бисквитки, връщане на страницата. Това струва около 10 кредита. След като Auto кешира работеща сесия за този хост, последващите извиквания преминават през Single за 2 кредита. Така второто извикване е 5 пъти по-евтино от първото, а всяко следващо запазва ниската цена, докато сесията е активна. Измерихме това в prod по време на пускането: изходите без бисквитки (веднъж намерени) се възпроизвеждат за точно 2 кредита на извикване спрямо 10, които струваха преди, когато всяка заявка минаваше през Proxy Finder.
Второто число: неуспешните нива не се таксуват. Ако Auto опита три проксита и всяко върне 403, преди четвъртото да достави, се отчитат само кредитите за четвъртото. Плащате за доставено съдържание, не за търсенето.
Това е основната стойност. Скъпото ниво се изпълнява веднъж, евтиното се изпълнява завинаги след това, а вие не трябва да пишете логиката за кеширане сами.
Две други поведения си струва да се отбележат, защото решават реални проблеми в production:
Целите с гео-ограничения спират да хабят изходи. Когато даден сайт връща 451 (или междинна страница за правно блокиране) за повечето изходи, Auto научава кои държави реално са доставили съдържание. При следващото извикване първо изтегля нови изходи от тези държави и разпределя едновременното натоварване върху тях. Така един случаен успешен изход не се претоварва и не достига rate limit.
Validate се изпълнява на всяко ниво. Страница с грешно съдържание (гео-блок, който връща статус 200 с правно известие като тяло) никога не се отчита като успех. Ако вашият validate.data.fail казва "legal reasons", Auto продължава да търси, докато някое ниво не премине. Не кешираното ниво. Не произволно ниво. Ако нищо не премине, получавате честен отказ с реалната причина.
За напреднали потребители
Няколко настройки, които имат значение, след като започнете да пропускате голям обем през Auto.
timeout_ms е бюджет за цялата операция, не за отделно ниво. По подразбиране е 120 секунди. Auto го разпределя: всяко под-извикване получава минимума от своя естествен timeout и оставащия бюджет, а веригата спира да стартира нови нива, когато остане твърде малко време. Задайте 20,000 за работа с интерактивна латентност. Оставете стойността по подразбиране за масови обхождания, които толерират по-дълги опашки.
forceProxy е включено по подразбиране. Auto никога не докосва целта от изходния IP адрес на FourA, освен ако не зададете forceProxy: false. Едно предупреждение: някои сайтове (интерактивен Cloudflare с ограничение по доверие на IP) всъщност работят по-добре от чист IP адрес на център за данни, отколкото от residential изход с ниско доверие. Така че 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 схема вижте предишното ръководство в Правилата Validate сега решават какво се счита за успех.
Какво предстои
Две неща са в плана за Auto в момента.
Проверката на сесиите е следваща в Dashboard. В момента сесиите, които Auto пази за всеки host, са вътре в услугата и няма какво да прегледате, когато дебъгвате проблеми от ваша страна. Подготвяме изглед на сесиите за всеки host, за да виждате кешираните сесии, тяхната възраст, колко време ще живеят и историята на стъпките зад всяка от тях. Добавяме и бутон за ръчно прекъсване на сесия, когато целта ви се промени и знаете, че кешът е грешен.
След това следва по-строг контрол на разходите. Твърдо ограничение на кредитите за всеки request (никога не харчете повече от X за това извикване, върнете ясна грешка при надвишаване) и режим "single-only" за екипи, чиито цели никога не се нуждаят от браузър стъпка. И двете опции са зад флагове днес.
Целта на Auto е да не мислите кой продукт да извикате. Това не означава, че не можете да проверите какво се е случило. Всеки response съдържа стъпката, която е изпълнил, и сесията, която е създал. Прочетете тези две полета и ще знаете точно защо вашите извиквания струват толкова, колкото струват.