Reguły validate decydują teraz o tym, co jest sukcesem

Reguły validate w twoim request określają teraz sposób klasyfikacji każdego wyniku. Zdefiniuj 403 jako akceptowalny, a zwrócony status 403 zostanie uznany za sukces, rozliczony jako sukces i trafi do twojego panelu Activity obok statusów 200.

To z pozoru drobna zmiana. W praktyce zmienia sposób mierzenia skuteczności scrapingu na dużą skalę.

Jak to działa

Każdy request do FourA otrzymuje jeden z siedmiu wyników, które decydują o rozliczeniach i analityce. Tylko success podlega opłacie. Pozostałe dzielą się w zależności od źródła błędu:

application_fail i application_error, gdy strona docelowa odrzuciła połączenie lub zwróciła treść błędu
client_error, gdy wysłany request był nieprawidłowo sformatowany
service_fail, service_error i rate_limit, gdy request został zablokowany po naszej stronie

Przed tą zmianą sukces oznaczał dokładnie jedno: HTTP 200. Status 403 był zawsze klasyfikowany jako application_fail, nawet jeśli właśnie takiego response oczekiwał twój kod. (Niektóre API z danymi sportowymi zwracają 403 dla rynków z blokadą regionalną i to jest sygnał, na który czeka twoja aplikacja.)

Teraz decyduje twój blok validate. Request przetwarza twoje reguły podczas wykonywania. Jeśli response je spełnia, wynik to 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"] }
    }
  }'

To traktuje 200 i 403 jako prawidłowe kody statusu. Jeśli treść odpowiedzi zawiera znacznik strony weryfikacyjnej lub komunikat o braku dostępu, żądanie kończy się niepowodzeniem. Wszystko inne to success.

Dwie zasady do zapamiętania:

Bez validate zachowanie się nie zmienia. Żądania, które nie deklarują walidacji, są nadal rozliczane wyłącznie na podstawie HTTP 200. Wymaga to świadomego włączenia.
validate działa w obie strony. Reguły akceptacji zatwierdzają, a reguły odrzucenia odrzucają. Można je łączyć. Możesz więc zaakceptować [200, 403] i nadal oznaczyć żądanie jako nieudane, jeśli treść zawiera nieprawidłowe dane.

Wpływ

Ta zmiana ma największe znaczenie dla zespołów, których cele zwracają odpowiedzi inne niż 200, a które są dla nich faktycznie przydatne.

Przykłady z zapytań, które widzimy codziennie:

API z danymi sportowymi zwracające 403 dla rynków z blokadą regionalną (nadal przydatne dane, nadal warte rejestrowania jako sukces)
Endpointy wyszukiwania e-commerce zwracające 404, gdy SKU jest niedostępny (sygnał odczytywany przez kod, a nie błąd)
API strumieniowe i obsługujące częściową zawartość, które zwracają 206

Przed tą zmianą zespoły te prowadziły własne rozliczenia na podstawie naszych logów Activity. Nie mogły ufać kolumnie outcome, ponieważ ich definicja sukcesu różniła się od naszej. Były rozliczane według liczby, która tak naprawdę nie miała dla nich znaczenia.

Teraz kolumna ta odzwierciedla rzeczywistość. Zakładka Activity w Dashboardzie pokazuje to, co zostało zdefiniowane przez Ciebie jako sukces, a nie to, co my założyliśmy. Twoje rozliczane sumy są zgodne z tym, co samodzielnie zliczasz (wczesne wyniki: zmiana działa tylko w przód, więc starsze wiersze w Activity zachowują swoją pierwotną klasyfikację).

Praktyczny efekt dla zadań scrapingu: mniej kroków uzgadniania danych między Twoim potokiem a naszą fakturą. Jeśli walidacja treści odpowiedzi była już przeprowadzana po fakcie, możesz przenieść tę regułę bezpośrednio do żądania i przestać utrzymywać równoległy zestaw reguł sukcesu/błędu poza naszym API. Jedna definicja tego, czy żądanie zasłużyło na miejsce w Twoim zbiorze danych, zamiast dwóch sprzecznych.

Zachowaliśmy jednak zabezpieczenie. Jeśli nie przekażesz bloku validate, nic się nie zmienia. Klasyfikator powraca do zasady „200 oznacza sukces”, więc żądania, które działały wczoraj, działają tak samo dzisiaj.

Dla zaawansowanych użytkowników

validate przyjmuje trzy niezależnie działające zestawy reguł: status, headers oraz data. Każdy z nich przyjmuje opcjonalne listy accept i 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"] }
    }
  }'

Wymaga to:

Status to 200 lub 304
Response deklaruje typ zawartości JSON
Body zawiera pole price
Body nie zawiera komunikatu o przerwie technicznej ani strony weryfikacji

Jeśli którakolwiek reguła nie zostanie spełniona, wynikiem jest application_fail. Jeśli wszystko przejdzie pomyślnie, jest to success. Klasyfikator działa wewnątrz samego requestu, więc unikasz narzutu round-trip, którego wymagałby osobny krok walidacji.

W połączeniu z followRedirects: podążaj do pięciu przeskoków, a następnie zwaliduj ostateczny response. Przekierowanie typu bait-and-switch z czystego URL na stronę weryfikacji kończy się jawnym błędem zamiast zanieczyszczać Twój zbiór danych.

Wskazówka z prowadzenia naszych własnych scraperów: deklaruj wzorce data.fail agresywnie. 200 OK ze stroną weryfikacji w środku to najczęstszy cichy tryb awarii w chronionych serwisach. Traktuj body jako źródło prawdy, a nie kod statusu.

Pełny schemat oraz opis łączenia poszczególnych pól validate zawiera dokumentacja requestu.

Co dalej

Pracujemy nad bogatszymi regułami: dopasowywaniem regex dla data, ustrukturyzowanymi predykatami JSON-path i bardziej elastycznym dopasowywaniem nagłówków. Zasada pozostaje ta sama. Deklarujesz, jak wygląda sukces, a API respektuje to end-to-end, od requestu aż po fakturę.

Kiedy Twój scraper przestaje działać, powinien wyraźnie o tym informować. A kiedy działa zgodnie z regułami, które sam napisałeś, to metryka, na której naprawdę możesz polegać.