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

Правилата на вашата заявка за validate вече определят как се класифицира всеки резултат. Обявете 403 за приемлив статус и полученият 403 се зачита за успех, таксува се като успех и се появява във вашия Activity фийд редом с вашите 200 статуси.

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

Как работи

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

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

Преди тази промяна успех означаваше точно едно нещо: HTTP 200. Статус 403 винаги беше application_fail, дори ако знаехте, че именно 403 е отговорът, който очаквате. (Някои API за спортни данни връщат 403 за пазари с географски ограничения и точно това е сигналът, който вашият код чака.)

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

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "X-API-Key: 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 като валидни статус кодове. Ако тялото съдържа маркер за страница за верификация или низ за отказан достъп, заявката е неуспешна. Всичко останало е success.

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

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

Влияние

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

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

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

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

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

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

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

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

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

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "X-API-Key: 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"] }
    }
  }'

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

• Status е 200 или 304
• Response декларира JSON content type
• Body съдържа поле price
• Body не съдържа съобщение за поддръжка или страница за верификация

Ако някое правило се провали, резултатът е application_fail. Ако всичко премине успешно, резултатът е success. Класификаторът се изпълнява вътре в самата заявка, така че си спестявате мрежовото забавяне от отделна стъпка за валидация.

В комбинация с followRedirects: следвайте до пет пренасочвания, след което валидирайте крайния response. Пренасочване от чист URL към страница за верификация се проваля отчетливо, вместо да замърсява вашите данни.

И един съвет от поддръжката на собствените ни скрапери: дефинирайте шаблони за data.fail агресивно. 200 OK със страница за верификация в нея е най-честият скрит проблем при защитени сайтове. Приемайте тялото на отговора за меродавно, а не статус кода.

За пълната схема документацията на request reference описва всяко validate поле и как се комбинират.

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

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

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