Когда у сайта есть открытый обмен данными и разбор не нужен

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

Две недели в мусор. Обидно.

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

Первым делом вкладка сети, фильтр по XHR и Fetch. Пролистываешь каталог на две страницы вниз и смотришь, что улетело.

А если каталог грузится сразу целиком, без подгрузки? Тогда в сети пусто.

Тогда ищите данные в самой странице. Их там обычно два вида.

Первый: разметка для поисковых систем, <script type="application/ld+json">. Лежит почти на каждом магазине, внутри название, артикул, наличие, иногда весь список товаров страницы. Разбирать её приятнее любых селекторов, потому что она не ломается от смены оформления.

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

Проверка занимает минуту, а экономит те самые две недели.

подскажите, а если такой обмен есть, его же могут закрыть в любой момент? страшно строить на нём весь прогон

Могут, и закрывают. Поэтому я держу оба пути: основной берёт данные напрямую, запасной разбирает страницу.

Схема простая. Прогон дёргает адрес обмена, проверяет, что в ответе пришёл ожидаемый набор полей, и работает дальше. Если пришёл HTML вместо JSON, или число полей упало, прогон сам переключается на разбор страницы и пишет в лог отметку. Разбор при этом медленнее и беднее, но каталог собирается, а я вижу отметку и спокойно разбираюсь, что там поменялось.

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

Третье. Смотрите на заголовки, которые шлёт браузер к этому адресу. Обычно там пара обязательных: свой заголовок с версией клиента, иногда токен, иногда просто Referer. Скопируйте их один в один, и не выдумывайте лишнего. Половина жалоб на «обмен отвечает четыреста третьим» это забытый заголовок.

Проверил на трёх магазинах из своего списка. У двух нашёлся тот самый INITIAL_STATE, у третьего разметка для поисковиков со всеми полями.

curl -s "https://shop.example/api/catalog?page=1&limit=100" \
  -H "Accept: application/json" \
  -H "X-Requested-With: XMLHttpRequest" \
  -H "Referer: https://shop.example/catalog/" | jq '.items | length'
# 100

Сто товаров одним запросом, поля богаче, чем на странице.

Ограничение на странице тоже потрогай. Часто limit можно поднять до пятисот, и каталог уезжает за пяток запросов.

Поднял до трёхсот, на пятистах отвечает урезанным набором. Переписал прогон на прямой обмен, разбор страницы оставил запасным путём по совету mnogoruk.

Каталог, который собирался сорок минут, собрался за три. Тема мне дорого обошлась, но пусть висит для тех, кто повторит мои грабли.