Цепочки редиректов ломают скраперы. Бинарные ответы повреждаются при декодировании в текст. Две проблемы, которые возникают постоянно, как только вы перерастаете этап "получить страницу, распарсить HTML".
Мы выпустили две новые опции запроса для решения обеих задач: followRedirects и returnBuffer. Они уже доступны в API.
Как это работает
Управление редиректами с помощью followRedirects
Большинство API для скрапинга обрабатывают редиректы как булево значение: следовать за ними или нет. Это работает ровно до тех пор, пока вы не столкнетесь с зацикленной цепочкой редиректов или пока вам не понадобится сам промежуточный ответ 302 для извлечения трекингового параметра.
Параметр followRedirects в FourA принимает целое число от 0 до 20. Не указывайте его (или задайте 0), и вы получите исходный ответ с редиректом, включая все headers. Укажите 5, и request выполнит до пяти переходов перед возвратом итогового ответа.
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/short-link",
"followRedirects": 3,
"unblocker": true
}'
Это отслеживает до трех редиректов. Если цепочка завершается за два, вы получаете финальную страницу. Если она длиннее трех, вы получаете то, что вернул третий переход.
Эта разница важнее, чем кажется. Сайты электронной коммерции перенаправляют через трекинговые URL перед переходом на страницу товара. Такие редиректы нужно обрабатывать. Но партнерские сети и сервисы сокращения ссылок иногда создают цепочки глубиной в шесть, семь, восемь переходов. А некоторые циклы редиректов не завершаются вовсе. Ограничение точным числом позволяет собирать данные и не зависать в бесконечном цикле, сжигающем timeout вашего request.
Раньше приходилось отправлять request с отключенными редиректами, вручную парсить header Location и отправлять следующий request. Это как минимум два вызова API, удвоенная задержка и лишний код для поддержки. Теперь это один вызов с числовым параметром.
Необработанные бинарные ответы с returnBuffer
При сборе изображений, PDF или данных protobuf декодирование текста повреждает данные. HTTP-библиотека считает response текстом, применяет определение кодировки и незаметно искажает каждый неподходящий байт. Protobuf становится нечитаемым. Заголовки изображений ломаются. В итоге вы получаете поврежденные файлы без понятного сообщения об ошибке.
Параметр returnBuffer указывает API полностью пропустить декодирование текста.
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-image.jpg",
"returnBuffer": true
}'
Тело response возвращается в виде необработанных байтов (в формате base64 внутри JSON response). Декодируйте его на своей стороне и вы получите ровно то, что отправил сервер. Никаких предположений о charset, никаких конвертаций кодировки, никакого незаметного повреждения данных.
Это было одно из самых частых обращений в поддержку: пользователи собирали изображения товаров или каталоги в PDF и получали файлы, которые не открывались. Решение всегда было одним и тем же, но теперь для этого есть флаг вместо обходных путей.
Результаты
Обе функции сокращают количество API вызовов на задачу. followRedirects устраняет циклы ручной обработки цепочек redirect. returnBuffer устраняет цикл «загрузить, понять, что данные повреждены, запросить повторно с другими параметрами».
Для целей с большим количеством redirect (партнерские ссылки, сокращатели URL, цепочки трекинга в e-commerce) мы наблюдали снижение количества request на 40-60% в ранних тестах при переходе с ручной обработки redirect на followRedirects. А для задач по сбору бинарных данных (изображения товаров, скачивание документов) returnBuffer превращает многоэтапный обходной путь в одну опцию (по ранним результатам).
Это не броские функции. Это вещи, о которых не думаешь, пока парсер не упадет в три часа ночи из-за того, что сайт добавил лишний шаг redirect в процесс оформления заказа.
Для опытных разработчиков
Комбинируйте followRedirects с валидацией response для точного контроля над цепочками redirect. Следуйте по redirect, но завершайте request с ошибкой, если конечный пункт назначения упирается в ограничение:
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/12345",
"followRedirects": 5,
"unblocker": true,
"validate": {
"status": { "fail": [403, 503] },
"data": { "fail": ["Access Denied", "captcha"] }
}
}'
Выполняется до пяти перенаправлений, после чего проверяется финальный response. Если сайт перенаправил вас на страницу верификации или заглушку с отказом в доступе, request завершается с чистой ошибкой. Никаких мусорных данных, которые пришлось бы фильтровать на следующих этапах.
Для сбора бинарных данных используйте returnBuffer в связке с HEAD requests, если нужно проверить тип контента перед скачиванием больших файлов. FourA корректно обрабатывает HEAD, позволяя проверять headers без загрузки body. Проверьте Content-Type, решите, стоит ли скачивать файл, и выполните полный request с returnBuffer: true.
А если вы используете browser tasks для сайтов со сложным JavaScript, обратите внимание, что эти параметры относятся к прямому HTTP engine. Browser requests обрабатывают перенаправления через встроенную навигацию браузера, которая переходит по ним по умолчанию без ограничений.
Что дальше
Мы работаем над добавлением новых параметров управления на уровне request через API: кастомный DNS resolution, настройка timeout для отдельных фаз и параметры обработки сертификатов. Цель заключается в полном контроле профиля браузера через чистый интерфейс REST без инфраструктурных накладных расходов.
Если вам нужна конкретная опция, дайте знать. В dashboard уже отображается статистика выполнения ваших requests с этими новыми параметрами, так что вы можете оценить разницу самостоятельно.