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

Правилата за validate вече определят какво се счита за success

Декларирайте кои responses се считат за success с помощта на правила за validate. Не-200 responses, които приемате, вече се таксуват правилно и се показват като success във вашия Activity feed.

apivalidationoutcomesbilling

Правилата за validate на вашата request вече определят как се класифицира всеки резултат. Декларирайте 403 като приемлив и доставеният 403 се счита за success, таксува се като success и се появява във вашия Activity feed заедно с вашите 200s.

Това звучи дребно. То променя начина, по който измервате точността на scraping в голям мащаб.

Как работи

Всяка request към FourA получава един от седем outcomes, които определят таксуването и анализите. Само success се таксува. Останалите се разделят според това по чия вина е неуспехът:

  • application_fail и application_error за случаите, когато целевият сайт е отказал достъп или е върнал тяло с грешка
  • client_error, когато изпратената от вас request е била неправилно форматирана
  • service_fail, service_error и rate_limit, когато нещо от наша страна е блокирало request

Преди тази промяна success означаваше точно едно нещо: HTTP 200. Код 403 винаги се класифицираше като application_fail, дори ако знаехте, че този 403 е точно търсеният от вас response. (Някои спортни APIs за данни връщат 403 за географски ограничени пазари и това е сигналът, който вашият код чака.)

Сега вашият validate блок взема решението. Request изпълнява вашите правила по време на изпълнение. Ако response ги удовлетворява, резултатът е success.

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/api/feed",
    "unblocker": true,
    "validate": {
      "status": { "accept": [200, 403] },
      "data": { "fail": ["captcha", "Access Denied"] }
    }
  }'

Това третира 200 и 403 като валидни статус кодове. Ако тялото съдържа CAPTCHA маркер или низ за отказан достъп, request се проваля. Всичко останало е success.

Две правила, които трябва да запомните:

  1. Без validate поведението остава непроменено. Requests, които не декларират валидиране, все още се таксуват само при HTTP 200. Вие избирате дали да се включите.
  2. validate работи и в двете посоки. Правилата за accept пропускат, а правилата за fail отхвърлят. Те се комбинират. Така можете да приемете [200, 403] и пак да отчетете неуспех, ако тялото съдържа грешно съдържание.

Влияние

Промяната е най-важна за екипи, чиито цели връщат различни от 200 responses, които те всъщност искат.

Примери от requests, които виждаме ежедневно:

  • Спортни APIs за данни, които връщат 403 за географски ограничени пазари (все още полезни данни, които си струва да бъдат записани като success)
  • E-commerce търсещи endpoints, които връщат 404, когато даден SKU е изчерпан (сигнал, който вашият код разчита, а не грешка)
  • APIs за стрийминг и частично съдържание, които връщат 206

Преди промяната тези екипи водеха собствено счетоводство върху нашите Activity logs. Те не можеха да се доверят на колоната outcome, защото тяхната дефиниция за success не съвпадаше с нашата. Те бяха таксувани спрямо число, което всъщност не ги интересуваше.

Сега колоната отразява реалността. Разделът Activity във вашия Dashboard показва това, което вие сте дефинирали като success, а не това, което ние сме предположили. Вашите таксувани суми съвпадат с това, което вие сами бихте преброили (ранни резултати: промяната се прилага само напред, така че по-старите редове в Activity запазват първоначалната си класификация).

Практическият ефект върху задача за scraping: по-малко стъпки за съгласуване между вашия pipeline и нашата фактура. Ако вече сте извършвали валидиране на response body след получаването му, можете да преместите това условие в самата request и да спрете да поддържате паралелен набор от правила за преминаване и неуспех извън нашия API. Една дефиниция за това дали дадена request е заслужила мястото си във вашия набор от данни, вместо две, които се разминават.

Но запазихме предпазната мрежа. Ако не подадете validate блок, нищо не се променя. Класификаторът се връща към "200 означава success", така че requests, които са работили вчера, работят по същия начин и днес.

За напреднали потребители

validate приема три набора от правила, които се изпълняват независимо: status, headers и data. Всеки от тях приема незадължителни списъци accept и fail.

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/9876",
    "followRedirects": 5,
    "unblocker": true,
    "validate": {
      "status": { "accept": [200, 304] },
      "headers": { "accept": { "content-type": "application/json" } },
      "data": { "accept": ["\"price\":"], "fail": ["maintenance", "captcha"] }
    }
  }'

Това изисква:

  • Статусът да е 200 или 304
  • Response да указва JSON content type
  • Тялото да съдържа поле за цена
  • Тялото да не съдържа съобщение за поддръжка или CAPTCHA капан

Ако някое правило се провали, резултатът е application_fail. Ако всичко премине, резултатът е success. Класификаторът работи вътре в самата request, така че избягвате допълнителното мрежово забавяне (round trip), което би коствала отделна стъпка за валидиране.

В комбинация с followRedirects: проследяване на до пет пренасочвания, след което се валидира финалният response. Подмяната на съдържанието (bait-and-switch) от чист URL към CAPTCHA бариера се проваля чисто, вместо да замърсява вашия набор от данни.

И един съвет от работата с нашите собствени scrapers: декларирайте шаблони за data.fail агресивно. Отговор 200 OK с CAPTCHA вътре е най-често срещаният скрит режим на грешка (silent failure) при защитените сайтове. Третирайте тялото като меродавно, а не статус кода.

За пълната схема, справката за request изброява всяко поле на validate и как се комбинират те.

Какво предстои

Работим върху по-богати примитиви за правила: regex съвпадения за data, структурирани JSON-path предикати и по-гъвкаво съвпадение на headers. Принципът остава същият. Вие декларирате как изглежда success; API го зачита изцяло (от самата request до вашата фактура).

Когато вашият scraper се счупи, той трябва да сигнализира шумно за това. А когато работи съгласно правилата, които сами сте написали, това е число, на което наистина можете да се доверите.