Парсинг и API — не взаимоисключающие технологии, а разные способы получить данные из конкретного источника. Если у источника есть подходящий официальный API, сначала проверяют его поля, правила доступа и обработку ошибок. Если нужные наблюдения доступны только на веб-странице, оценивают допустимость и техническую выполнимость сбора на небольшой выборке. Для данных поставщика правильным источником нередко оказывается его прайс-лист. Формат доставки выбирают отдельно: данные, собранные с веб-страниц, можно передать в CSV, а полученные через API — выгрузить в Excel. Поэтому вопрос «парсер или API» лучше заменить двумя: откуда брать данные и как передавать результат.
Чем API отличается от веб-парсинга
В HTTP клиент отправляет запрос с методом и адресом ресурса, а сервер возвращает ответ со статусом и, при наличии, содержимым. Это базовая модель протокола, описанная в RFC 9110. Конкретный API добавляет к ней собственный контракт: доступные операции, поля, параметры, авторизацию и ошибки.
OpenAPI Specification 3.2.0 определяет стандартное, не зависящее от языка описание интерфейса HTTP API. Такое описание помогает понять возможности сервиса, но не отвечает за владельца данных: нужный метод или поле всё равно должны присутствовать в документации конкретного источника.
Веб-парсинг работает с представлением данных на странице. Здесь контракт приходится фиксировать самим: где находится поле, как различить продавца и регион, что считать отсутствием значения и как заметить изменение разметки. Прайс-лист — третий вариант источника: в нём важны колонки, кодировка, единицы, дата файла и сопоставление артикулов.
| Способ получения | Что проверять первым | Типичный риск решения |
|---|---|---|
| Официальный API | Доступ, схема, нужные поля, идентификаторы, ошибки и изменения версий | Интерфейс существует, но не покрывает требование или доступен на других условиях |
| Веб-сбор | Допустимость источника, наблюдаемые поля, условия страницы и результат выборки | Поле или разметка меняются, регион и продавец не зафиксированы, пропуск принят за ноль |
| Прайс-лист | Канал передачи, дата, структура колонок, коды товаров, единицы и дубли | Шаблон или справочники меняются, файл опаздывает, артикулы не сопоставлены |
Ни один столбец этой таблицы не означает «лучше всегда». Выбирать можно только после сверки с задачей и конкретным источником.
Начните не с технологии, а с требования к данным
До обсуждения API или парсера полезно записать единицу наблюдения. Для мониторинга цен это может быть сочетание товара клиента, источника, продавца, региона и времени проверки. Затем перечисляют обязательные поля и состояния качества. Например, пустая цена, недоступная карточка и неоднозначное совпадение — три разных результата, их нельзя сводить к одному нулевому значению.
Рассмотрим вымышленный учебный сценарий.
Учебному магазину нужен ежедневный сверочный файл. У партнёра есть документированный API с артикулом, ценой и остатком, но без продавца и текста акции. Поставщик передаёт CSV с оптовой ценой и собственным артикулом. На публичной странице условного магазина видны продавец, регион, цена и наличие, однако стабильного артикула нет. Итоговая схема требует SKU клиента, ссылку на источник, цену и её тип, наличие, продавца, регион, время проверки, тип совпадения и статус качества.
В этом сценарии нет одного победителя. API удобен для полей, которые он действительно отдаёт. Файл остаётся исходным документом поставщика. Данные со страницы требуют отдельного сопоставления и проверки на выборке. Итоговая строка может объединять подтверждённые наблюдения, но происхождение каждого поля должно сохраняться.
Матрица выбора источника
| Критерий | API | Веб-страница | Файл поставщика |
|---|---|---|---|
| Доступ | Проверить правила и способ авторизации конкретного API | Зафиксировать допустимый сценарий и условия страницы | Зафиксировать владельца, канал и расписание передачи |
| Покрытие полей | Сопоставить документированную схему с обязательными полями | Подтвердить наблюдаемые поля на выборке | Сопоставить реальные колонки с целевой схемой |
| Идентификаторы | Проверить связь идентификатора API с каталогом клиента | Согласовать признаки точного товара, варианта и аналога | Настроить связь артикула поставщика с каталогом |
| Изменения | Отслеживать документацию и версию схемы | Хранить тестовые страницы и проверять изменения разметки | Контролировать колонки, кодировку, единицы и справочники |
| Качество | Проверять типы, обязательные поля, ошибки и время | Сохранять ссылку, условия наблюдения и статус исключения | Проверять дату, обязательные колонки, дубли и сопоставление |
Полная рабочая матрица также должна называть владельца изменений и правила обслуживания. «API не ответил», «страница изменилась» и «файл не пришёл» — разные события, хотя для получателя все они могут выглядеть как пропуск строки.
Источник данных и формат доставки — разные решения
API часто одновременно называют и источником, и способом выдачи результата. Из-за этого требования смешиваются. Источник отвечает на вопрос, где находится наблюдение. Доставка — куда и в каком контракте попадёт уже проверенная запись.
| Доставка | Что нужно согласовать | Граница ScanHub |
|---|---|---|
| XLSX или CSV | Колонки, типы, пустые значения, кодировка, имя файла и приёмка | Один согласованный Excel или CSV входит в базовый формат |
| API | Методы, схема, доступ, ошибки, версия и операционный владелец | Подключается и оценивается отдельно |
| SFTP | Доступ, каталоги, имена файлов, контроль поступления и инциденты | Подключается и оценивается отдельно |
| Хранилище или BI | Целевая модель, права, преобразования, хранение и изменения схемы | Согласуется как отдельная интеграция |
Например, веб-сбор не обязывает получать CSV, а официальный API источника не обязывает строить ещё один API на выдаче. В ScanHub базовый результат передаётся в согласованном Excel или CSV; API, SFTP, хранилище, BI и дополнительная аналитика оцениваются отдельно.
Проверка решения на небольшой выборке
- Назовите решение и владельца. Какое действие будет принято по данным и кто отвечает за него?
- Перечислите источники и условия доступа. Не переносите правило одного API или сайта на остальные.
- Определите сущности и идентификаторы. SKU, модель, продавец и карточка — не одно и то же.
- Разделите обязательные и дополнительные поля. Пустое обязательное поле должно давать явное исключение.
- Зафиксируйте регион, продавца и другие условия. Без них две цены могут описывать разные предложения.
- Согласуйте частоту как требование проекта. Она не следует автоматически из выбранной технологии.
- Опишите точное совпадение, вариант, аналог и спорный случай. Неоднозначность нельзя скрывать.
- Задайте проверки. Типы, дубли, время, ссылка на источник и причина пропуска должны быть видны.
- Отделите готовые строки от исключений. Это делает приёмку проверяемой.
- Выберите базовую доставку. Дополнительную интеграцию оценивайте отдельным контуром.
- Проверьте всё на части данных. Выборка должна подтвердить поля, правила и вид результата до расширения объёма.
Если задача связана с рынком и переоценкой, посмотрите практический процесс мониторинга цен. Описание границ самого мониторинга цен конкурентов помогает понять, какие вводные проверяются на выборке и что остаётся отдельной работой.
Короткий вывод
Выбирайте не между модными словами, а между проверенными источниками для конкретной схемы данных. Официальный API подходит, когда его текущий контракт закрывает поля и условия задачи. Прайс-лист подходит, когда именно поставщик передаёт нужные данные в пригодной структуре. Веб-сбор рассматривают, когда требуемые наблюдения находятся на странице и проверка подтверждает допустимый и технически устойчивый сценарий. Доставку результата согласуют следующим, отдельным решением.
Проверить задачу на выборке можно по списку источников, обязательных полей, требуемой частоте и нескольким контрольным примерам. Такая проверка подтверждает конкретный контур; она не обещает универсальное покрытие источников или полей.
Источники и границы материала
- RFC 9110: HTTP Semantics, IETF / RFC Editor, июнь 2022 года; проверено 29 июля 2026 года.
- OpenAPI Specification 3.2.0, OpenAPI Initiative, 19 сентября 2025 года; проверено 29 июля 2026 года.
- Описание продуктов и границ ScanHub; проверено 29 июля 2026 года.
Применить к вашей задаче
Нужны регулярные данные, а не разовая выгрузка?
Покажите список товаров и источников. Проверим доступность данных и предложим структуру первого теста.
