← Все статьи
Обновление продукта 5 минут чтения

Правила validate теперь определяют, что считать успехом

Указывайте, какие ответы считать успешными, с помощью правил validate. Принятые вами ответы с кодами, отличными от 200, теперь тарифицируются корректно и отображаются как успешные в ленте Activity.

apivalidationoutcomesbilling

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

Это кажется незначительным изменением. Но оно меняет то, как вы измеряете точность скрапинга в масштабе.

How It Works

Каждый request к FourA получает один из семи результатов, которые определяют тарификацию и аналитику. Тарифицируется только success. Остальные делятся в зависимости от того, на чьей стороне произошел сбой:

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

До этого изменения успех означал ровно одно: HTTP 200. Код 403 всегда классифицировался как application_fail, даже если вы знали, что именно этот 403 вам и нужен. (Некоторые API спортивных данных возвращают 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], но все равно помечать запрос как неудачный, если тело содержит нежелательный контент.

Impact

Это изменение наиболее важно для команд, чьи целевые ресурсы возвращают ответы, отличные от 200, которые на самом деле им нужны.

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

  • API спортивных данных, возвращающие 403 для гео-ограниченных рынков (это все еще полезные данные, которые стоит фиксировать как успех)
  • Endpoints поиска в e-commerce, возвращающие 404, когда товара нет в наличии (сигнал, который считывает ваш код, а не сбой)
  • API стриминга и частичного контента, возвращающие 206

До этого изменения таким командам приходилось вести собственный учет поверх наших логов Activity. Они не могли доверять колонке outcome, потому что их определение успеха не совпадало с нашим. Им выставляли счета на основе показателей, которые их не интересовали.

Теперь эта колонка отражает реальность. Вкладка Activity в вашем Dashboard показывает то, что вы сами определили как успех, а не то, что предположили мы. Итоговые суммы в счетах соответствуют вашим собственным подсчетам (обратите внимание: изменения применяются только к новым запросам, поэтому старые строки в Activity сохраняют свою первоначальную классификацию).

Практический эффект для задач скрапинга: меньше шагов по сверке данных между вашим пайплайном и нашим инвойсом. Если вы уже выполняли валидацию тела response постфактум, теперь вы можете перенести это условие прямо в сам request и больше не поддерживать параллельный набор правил успешности/ошибок за пределами нашего API. Одно определение того, заслуживает ли запрос места в вашем датасете, вместо двух противоречащих друг другу.

Но мы сохранили подстраховку. Если вы не передаете блок validate, ничего не меняется. Классификатор возвращается к правилу «200 означает успех», поэтому запросы, которые работали вчера, будут работать точно так же и сегодня.

For Power Users

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
  • Тело содержит поле цены
  • Тело не содержит уведомления о технических работах или ловушки CAPTCHA

Если хотя бы одно правило не выполняется, результатом будет application_fail. Если все проверки пройдены, возвращается success. Классификатор работает внутри самого запроса, поэтому вы экономите время на сетевых задержках, которые потребовались бы для отдельного шага валидации.

В сочетании с followRedirects: переход до пяти редиректов с последующей валидацией финального response. Подмена чистого URL на страницу с CAPTCHA корректно завершится ошибкой, не загрязняя ваш датасет.

И совет из опыта запуска наших собственных скраперов: активно объявляйте шаблоны в data.fail. Ответ 200 OK с CAPTCHA внутри — самый частый сценарий скрытого сбоя на защищенных сайтах. Считайте авторитетным тело ответа, а не код состояния.

Полную схему, описание каждого поля validate и правила их комбинирования можно найти в справочнике по request.

What's Next

Мы работаем над более гибкими примитивами правил: регулярными выражениями для data, предикатами на основе структурированных JSON-путей и более свободным сопоставлением заголовков. Принцип остается прежним. Вы определяете, как выглядит успех, а API соблюдает это на всех этапах: от выполнения запроса до выставления инвойса.

Когда ваш скрапер ломается, это должно быть очевидно. А когда он работает в соответствии с правилами, которые вы написали сами, полученным цифрам действительно можно доверять.