Что такое API-прокси?Прокси, который вызывают, а не настраивают

Поищите «API-прокси», и вы получите два ответа, не связанных друг с другом. Первый, в смысле управления API: тонкий слой перед собственным API, добавляющий аутентификацию, кэширование и ограничение скорости до того, как запросы достигнут вашего бэкенда. Второй, в смысле веб-скрейпинга: прокси, к которому вы обращаетесь по HTTP, а не настраиваете как host:port. Эта статья о втором значении, потому что именно его имеют в виду люди, спрашивающие, поможет ли API-прокси с заблокированным скрейпером.

И честная постановка такова: API-прокси, это не новый сетевой протокол и не новый вид IP. Это прокси, которым вы пользуетесь как вызовом функции. Вместо того чтобы арендовать списки IP, настраивать прокси в HTTP-клиенте и самостоятельно писать логику ротации и повторных попыток, вы отправляете один HTTP-запрос с токеном и целевым URL, а сервис выполняет проксирование на другой стороне этой конечной точки.

Поэтому реальное решение, это не «API-прокси против резидентного» или «API-прокси против датацентрового». Это неверная ось. Вопрос в том, хотите ли вы управлять прокси-слоем самостоятельно или потреблять его как API. Всё остальное в этой статье следует из этого единственного разделения.

Что такое API-прокси на самом деле

Обычный прокси, это один уровень переадресации: он делает запрос от вашего имени, чтобы источник видел его IP, а не ваш. Вы направляете на него клиента, устанавливая хост и порт, часто с именем пользователя и паролем, и ваш трафик проходит через него. Базовый случай в полном объёме рассмотрен в что такое прокси-сервер. API-прокси сохраняет ту же задачу и меняет только интерфейс к ней.

Вместо этого:

• Настроить http://user:[email protected]:8080 в HTTP-клиенте.
• Поддерживать список IP и ротировать по нему.
• Обнаруживать блокировки, повторять попытки с нового IP и откатываться.
• Поднять безголовый браузер, когда страница требует JavaScript.

Вы делаете это:

• Отправляете GET на https://api.crawlbase.com/?token=TOKEN&url=TARGET.
• Читаете ответ.

Ротация, пул IP, обнаружение блокировок, повторные попытки и опциональный рендеринг JavaScript, всё это происходит за этой конечной точкой. Вы перестали управлять инфраструктурой и начали вызывать функцию. В этом весь рефрейминг, и именно поэтому термин вызывает путаницу: «API», это не функция прокси, а механизм его доставки.

Сдвиг: от конфигурации к вызову функции

Разницу нагляднее всего видно по тому, где находится работа. С обычным прокси сложные части, на вашей стороне провода. Вы отвечаете за пул, политику ротации, проверки работоспособности, настройку под конкретные цели и уровень рендеринга. С API-прокси они перемещаются за конечную точку и становятся операционной проблемой кого-то другого. Вы отвечаете за одно: запрос, который отправляете, и ответ, который разбираете.

Это тот же сдвиг, который превратил серверы в бессерверные функции. Возможность не изменилась; изменилась граница того, чем вы управляете. API-прокси, это прокси-слой с переопределённой той же границей, и практическое следствие в том, что «скрейпить этот URL через доверенный IP, рендеря JS при необходимости» сворачивается от подсистемы, которую вы создаёте, до единственного HTTP-вызова, который вы делаете.

Как API-прокси обрабатывает один запрос

Снаружи это единственный вызов. Внутри конечной точки выполняется последовательность, которую иначе вам пришлось бы написать самостоятельно:

1. Вы отправляете HTTP-запрос на конечную точку API с токеном и целевым URL в качестве параметров.
2. Сервис аутентифицирует токен и решает, какой выходной IP использовать для этой цели.
3. Он отправляет запрос к цели через этот IP, выбирая датацентровый или резидентный в зависимости от того, насколько сильно защищён сайт.
4. Если страница требует JavaScript, он рендерит её в реальном браузере перед чтением результата.
5. Если цель блокирует или перехватывает запрос, он повторяет попытку с другого IP, не возвращая сбой вам.
6. Он возвращает окончательный ответ с телом и статусом в качестве ответа на ваш единственный вызов.

Смысл этого списка не в том, что шаги экзотические. Все шесть находятся за конечной точкой. Выбор IP на шаге 3, тот же компромисс между датацентровым и резидентным, который вы взвешивали бы сами; разница в том, что сервис взвешивает его для каждого запроса, а не вы заранее привязываетесь к одному пулу. Если вы хотите понять лежащее в основе решение, мы разбираем его в датацентровые vs резидентные прокси.

API-прокси vs обычный прокси: кто за что отвечает

Таблица, не таблица функций, потому что оба варианта могут достигать одних и тех же сайтов. Это карта того, где лежит ответственность. Читайте её как «кто за это отвечает», а не «что лучше».

Ни один столбец не является умным выбором абстрактно. Команда, которой нужно владеть выходными IP, закреплять сессии или работать с не-HTTP протоколом, захочет обычный прокси. Команда, которая хочет получать страницы и не хочет управлять скрейпинговой подсистемой, захочет API. Ошибка, считать API-прокси прокси другого сорта, а не другим местом для проведения границы.

Вызов на практике

Рефрейминг проще всего прочувствовать в одной команде. Нет конфигурации клиента, нет списка прокси, нет цикла ротации. Вы передаёте токен и нужную страницу в URL-кодировке и получаете страницу обратно. Сервис выбирает IP, рендерит при необходимости и повторяет попытку при блокировке до того, как ответит вам.

# No host:port, no IP list. Token plus target URL.
# The endpoint rotates, renders, and retries for you.
curl "https://api.crawlbase.com/?token=YOUR_TOKEN&url=https%3A%2F%2Fexample.com%2Fproduct%2F123"

# Need the page's JavaScript executed? Add one flag.
curl "https://api.crawlbase.com/?token=YOUR_TOKEN&url=...&javascript=true"

Всё, что было бы подсистемой (управление пулом, политика ротации, безголовый браузер, повторные попытки и откат), теперь является строкой запроса. Это вызов функции, заменяющий инфраструктуру. Та же идея, выходные IP, стоящие за одним адресом, чтобы вы перестали думать об отдельных прокси, описана в статье о backconnect-прокси против Crawling API; API-прокси, это конец спектра Crawling API, где адрес является HTTP-конечной точкой, а не единственным ротирующимся шлюзом.

Что API-прокси, это не

Поскольку название несёт вес, стоит прямо изложить несколько исправлений.

Это не новый протокол

API-прокси говорит на обычном HTTP. Не существует «протокола API-прокси», как существует протокол SOCKS. Если ваш трафик вообще не является веб-трафиком, правильным инструментом является ретрансляция на уровне сокетов, которую мы описываем в что такое SOCKS5-прокси. API-прокси специально предназначен для получения веб-страниц и API через управляемую конечную точку.

Он не является магически неблокируемым

Конечная точка улучшает ваши шансы, потому что ротирует доверенные IP и рендерит JavaScript, а не потому что обладает секретом. Защищённая цель всё равно сопротивляется, и сервис всё равно должен выбрать правильный класс IP и интеллектуально повторять попытки. Преимущество в том, что эта работа выполняется за вас, а не в том, что обнаружение прекратило существовать.

Он не то же самое, что прямой или обратный прокси по направлению

API-прокси в смысле скрейпинга является прямым прокси: он стоит на вашей стороне и обращается к открытому интернету для вас. Это не шлюз, защищающий сервер. Если вас интересует различие клиентской и серверной сторон, см. прямой vs обратный прокси. Слово «API» в названии описывает то, как вы его вызываете, а не в какую сторону он смотрит.

Когда управлять, а когда потреблять

Разрешите это с помощью определяющего вопроса, а не списка функций.

Управляйте обычным прокси, когда контроль является требованием

Выбирайте обычные прокси, когда нужно владеть выходным IP, удерживать один IP на протяжении длинной аутентифицированной сессии, маршрутизировать не-HTTP протоколы или строить кастомную логику, которую конечная точка не предоставляет. Если проксирование само по себе является частью вашего продукта или у вас есть инженерные ресурсы для хорошей настройки ротации и рендеринга, управление слоем, правильный выбор. Вы платите за это кодом, который поддерживаете, но получаете полный контроль над путём.

Потребляйте API-прокси, когда результат является требованием

Выбирайте API-прокси, когда вам нужны страницы, а проксирование, это сантехника, а не ваш продукт. Это большинство скрейпинговых задач: мониторинг цен, извлечение каталогов, результаты поиска, маркетинговые исследования в объёме. Вы отказываетесь от низкоуровневого контроля пути и получаете обратно время, которое потратили бы на построение и эксплуатацию скрейпинговой подсистемы. Для команды, чья цель, данные, этот обмен почти всегда правильный.

Или сохраните привычку и перенесите интеллект

Есть средний вариант, который вводит людей в замешательство, потому что размывает границу между двумя подходами. Смарт-прокси даёт вам конечную точку host:port, привычную конфигурацию, выполняя при этом ротацию, повторные попытки и выбор IP от API-прокси за ней. Вы сохраняете существующий клиент и при этом перестаёте управлять списками. Это операционная модель API-прокси в интерфейсе обычного прокси, и для многих команд это наименее разрушительный способ сделать переход.

Часто задаваемые вопросы

Что такое API-прокси простыми словами?

Это прокси, к которому вы обращаетесь по HTTP, а не настраиваете как host:port. Вы отправляете один запрос с токеном и целевым URL, и сервис выполняет проксирование (ротация IP, повторные попытки, опциональный рендеринг JavaScript) за этой конечной точкой, затем возвращает страницу. Вы вызываете функцию вместо управления инфраструктурой.

Чем API-прокси отличается от обычного прокси?

Задача проксирования одна; меняется только интерфейс. Обычный прокси, это host:port, который вы настраиваете в клиенте и управляете сами. API-прокси предоставляет ту же возможность как HTTP-конечную точку и управляет ротацией, повторными попытками при блокировках и рендерингом со своей стороны, поэтому вы поддерживаете один запрос, а не пул и логику ротации.

Использует ли API-прокси датацентровые или резидентные IP?

Как правило, и те, и другие. Хороший API-прокси выбирает класс IP для каждого запроса в зависимости от того, насколько сильно защищена цель, используя более дешёвые датацентровые IP на терпимых сайтах и резидентные на защищённых. Этот выбор, именно тот компромисс между датацентровым и резидентным, сделанный за вас за конечной точкой, а не вами заранее.

Подходит ли API-прокси для веб-скрейпинга?

Да, для большинства скрейпинга это более сильный строительный блок. Он устраняет части, которые обычно ломают скрейпер в масштабе: ротацию, обнаружение блокировок, повторные попытки и рендеринг JavaScript. Вы обмениваете низкоуровневый контроль над путём запроса на единственный вызов, возвращающий страницу, что является правильным обменом, когда цель, данные, а не сантехника.

Может ли API-прокси рендерить JavaScript?

Многие могут, за флагом. Вместо запуска собственного парка безголовых браузеров вы добавляете параметр к запросу, и сервис рендерит страницу в реальном браузере перед её возвратом. Это сворачивает целую подсистему рендеринга в один параметр строки запроса, что является наиболее ярким примером рефрейминга вызова функции.

«API-прокси», то же самое, что «API-шлюз»?

Не в этом контексте. API-шлюз, иногда называемый API-прокси в кругах управления API, стоит перед вашим собственным API, чтобы добавить аутентификацию, кэширование и ограничение скорости. API-прокси для скрейпинга, описанный в этой статье, направлен наружу для получения открытого интернета. Одна фраза, противоположное направление трафика, всегда уточняйте, какое значение подразумевает инструмент.

TA

Thomas Adewale

Технический писатель · Crawlbase

Технический писатель в Crawlbase, освещает прокси-сети, стратегии ротации и внутреннее устройство надёжного краулинга в больших масштабах.