01.12.2016 09:46
silenzushka 41 3100 Источник
image

В этой инструкции мы расскажем о том, как с помощью Fetchee Product API получить данные о товаре по URL на примере интернет-магазина lamoda.

Для тех, кто не читал нашу прошлую заметку — Product API будет полезен разработчикам, которым требуется получать данные о товарах из любого магазина, но которые не хотят тратить время на создание собственной системы парсинга или уже осознали, что open-source библиотеки обладают существенными ограничениями и требуют много времени на поддержку. Наш автоматический и не требующий настройки API для парсинга eCommerce данных даёт возможность сосредоточится на разработке основных функций вашего приложения. К тому же попробовать его очень просто. Детали под катом.

Для начала вам понадобится ключ доступа к API. Оставьте заявку на https://fetch.ee/ru/developers/. Мы предоставляем доступ всем желающим и обычно отвечаем на заявки в течении 24-х часов.

1. Отправка запроса на парсинг товара по URL


Обратите внимание, что API принимает только POST запросы в формате application/json на URL https://fetch.ee/api/v1/product:

{
   "url":"<URL ТОВАРА>",
   "api_key":"<API КЛЮЧ>",
   "callback_url":"<URL ДЛЯ ОТПРАВКИ РЕЗУЛЬТАТА ПАРСИНГА>"
}

Пример запроса для товара по адресу http://www.lamoda.ru/p/ug174awohj47/shoes-uggaustralia-uggi/ будет выглядеть следующим образом (мы добавили демонстрационный API-ключ, который проживёт пару дней):

curl -X POST -H "Content-type: application/json" -d "{\"url\": \"http://www.lamoda.ru/p/ug174awohj47/shoes-uggaustralia-uggi/\", \"api_key\": \"0e2bc30838d8bbbbbec787667c4ff34b\", \"callback_url\": \"http://requestb.in/onpdf2on\"}" https://fetch.ee/api/v1/product

Все параметры обязательные, если какого-то из них не будет, то сервер вернёт 403 ошибку, как и в случае неправильного API-ключа.

ВАЖНО: В примере указан временный callback_url. Он перестанет действовать через пару часов, заменяйте его своим URL, который можно получить на http://requestb.in.

Product API обрабатывает запросы асинхронно, время получения ответа может варьироваться от пары секунд до нескольких десятков минут. Это связано с нагрузкой на систему в конкретном географическом регионе. API отправит данные на указанный вами URL по завершении парсинга (callback_url).

Максимальное время ожидания составляет 30 минут, после чего в любом случае будет отправлен ответ с результатом или сообщение о невозможности завершить парсинг товара по указанному URL.

Для тестирования API удобно использовать сервис http://requestb.in. Заведите на нем новый контейнер (Create a RequestBin) и указывайте полученный URL в качестве callback_url. Все ответы от API будут приходить на него, просто обновляйте страницу браузере.

2. Поля и варианты ответа API


В ответе используются следующие поля:

  • success – результат отправки URL на парсинг;
  • id – уникальный ID запроса;
  • already_processed – запрос уже был недавно обработан;
  • not_shop – URL не принадлежит магазину;
  • not_product – по данному URL нет данных о товаре.

Любое из полей, кроме success, может отсутствовать.

Сразу после запроса, вы получите ответ в JSON формате. ID нужен для сопоставления отправленных вами запросов и полученных на callback_url ответов. В данном случае всё прошло отлично и товар был принят на парсинг.

{
  "success": true,
  "id": "583ea83a09e9497a0eb1b82a"
}

Такой ответ последует, если вы попытаетесь отправить на парсинг URL, который уже был обработан менее 6 часов назад. В данном случае вызова на callback_url не последует.

{
   "success":true,
   "id":"583ea83a09e9497a0eb1b82a",
   "already_processed":true
}

Данный ответ вы получите, если API уже знает, что указанный URL не относится к сайту интернет-магазина. Товар не добавляется на парсинг и вызова callback_url не будет. Мы ведём чёрный список сайтов, куда входят в том числе сомнительные и партнерские магазины (выступающие как витрины с товарами других магазинов).

{
   "success":false,
   "not_shop":true
}

Когда система знает, что по данному URL нет товара (страница категории, главная страница магазина и т.д.). Товар не добавляется на парсинг и вызова callback_url не будет.

{
   "success":false,
   "not_product":true
}

3. Получение результата парсинга


API отправляет POST запрос с ответом в JSON на указанный в callback_url адрес. Через 20 секунд мы получили такой результат парсинга:

{
   "id":"583ea83a09e9497a0eb1b82a",
   "url":"http://www.lamoda.ru/p/ug174awohj47/shoes-uggaustralia-uggi/",
   "created_at":"2016-11-30T10:21:46.865Z",
   "title":"Обувь угги UGG Australia",
   "price":22800,
   "currency":"RUB",
   "img_url":"https://fetch.ee/assets/item-images/583e/a843a9436d700e54ef37.jpg",
   "brand":"UGG Australia"
}

Рассмотрим полученный JSON более подробно. В ответе всегда присутствуют 3 обязательных параметра:

  • id – уникальный ID запроса;
  • url – окончательный URL товара (если были редиректы, или мы вырезали различные ненужные query_params из URL (UTM-метки, например);
  • created_at – время создания запроса на парсинг товара;

Любой из следующих параметров может отсутствовать:

  • title – название товара;
  • price – цена;
  • currency – код валюты (например, RUB, USD, EUR);
  • img_url – ссылка на изображение товара;
  • brand – производитель товара;
  • out_of_stock: true – когда товар отсутствует в продаже;
  • removed: true – когда товар вообще пропал из магазина и происходит перенаправление на страницу категории, главную страницу магазина или получаем 404 ответ от сервера;
  • not_shop: true – когда за время парсинга API определил, что URL не принадлежит магазину, хотя ранее принял запрос на обработку;
  • not_product: true – коза за время парсинга API определил, что URL не содержит информации о товаре, хотя запрос на обработку был принят;
  • unprocessed: true – когда Product API не смог получить ключевые параметры товара title или price.

Если Product API может быть вам полезен, оставляйте заявку на fetch.ee/ru/developers! Напишите в комментариях какие ещё параметры товаров вы бы хотели получать в дополнение к уже доступным?
Поделиться с друзьями
-->

Комментарии (41)


  1. Screatch
    01.12.2016 14:31
    #9941088
    +1

    Есть ли возможность получать несколько изображений товара через API?


    1. silenzushka
      01.12.2016 14:33
      #9941094

      Сейчас только одно. Под несколькими Вы имеете ввиду разные размеры картинки или все доступные в магазине ракурсы?


      1. Screatch
        01.12.2016 14:38
        #9941104
        +1

        Интересует прежде всего все доступные в магазине ракурсы.


        1. silenzushka
          01.12.2016 14:49
          #9941122
          +1

          Принято. Добавил в хотелки.


  1. evnuh
    01.12.2016 14:48
    #9941120

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


    1. silenzushka
      01.12.2016 14:52
      #9941130

      Эх, если бы мы умели сейчас делать рекомендации! Вот интересно, а что для Вас качественная рекомендация?

      • Похожий по названию товар;
      • Товар, который смотрели вместе данным товаром;
      • Похожий по фото товар;
      • Схожий по параметрам (категория, цвет, цена, какие-то meta-теги);
      • Товар, который покупают вместе в данным товаром.


    1. alekciy
      05.12.2016 12:12
      #9946376

      Попробуйте REES46 (ни какого отношения лично к данному сервису не имею). Имхо, лучше использовать под каждую задачу специализированное ПО. Парсинг должен оставаться парсингом.


  1. xytop
    01.12.2016 15:04
    #9941168

    Парсинг продукта заключается в парсинге микроразметки?


    1. silenzushka
      01.12.2016 15:11
      #9941198

      Микроразметка — только один множества используемых сигналов.


    1. silenzushka
      01.12.2016 15:23
      #9941234

      Если быть точным, то у нас сейчас 8 слоёв, которые анализируются на наличие и качество eCommerce данных. Строим планы на 9-й — визуальный, основанный на машинном зрении.


      1. Labunsky
        01.12.2016 17:24
        #9941646

        Машинное зрение для парсинга? У меня тут 4 десятка парсеров магазинов на простых регулярках с куда большим количеством информации. Иногда что-то ломается вместе с версткой, конечно, но чинить раз в полгода, ИМХО, явно проще, чем машинное зрение использовать для этого)


        1. silenzushka
          01.12.2016 18:18
          #9941742

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

          Что касается объема извлекаемой информации, нам были нужны только название, цена и изображение товара. По мере надобности добавляем новые параметры: бренд и категорию, например. Будем развивать API и дальше по мере появления новых потребностей пользователей.

          Напомню, Вы решаете задачу парсинга конкретного сайта, а мы — автоматического парсинга любого сайта. Интернет пестрит предложениями «купить парсер avito.ru или ikea.com», написать парсер для сайта и т.д. Мы даём API, которое сразу работает с любым магазином.


          1. Labunsky
            01.12.2016 19:12
            #9941890

            Вы решаете задачу парсинга конкретного сайта, а мы — автоматического парсинга любого сайта
            Не конкретного, а очень многих конкретных (да и решил уже давно, а не решаю) :)

            Как делать — решать вам, конечно же. Я просто выразил мысль, что в итоге затраченные усилия получатся куда выше, нежели у ручных паттернов (которые можно не трогать годами), а конечный пользователь разницы все равно не заметит


            1. silenzushka
              01.12.2016 20:27
              #9942042

              За мнение — спасибо. Но у нас кончилось терпение на 200-м сайте магазина заниматься этим рукоблудием. Сейчас парсим 5822 магазина. Мы бы повесились вручную паттерны делать.

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


              1. Labunsky
                01.12.2016 20:35
                #9942046

                А никто не говорит вручную писать ;)

                Лично я делал довольно просто — автоматическое выделение значимых подстрок слева и справа от каждого парсящегося параметра таким образом, чтобы остальные ссылки с того же магазина подходили под паттерн (в итоге получилась всего сотня-другая строк на все случаи жизни)

                Единственный минус такого подхода — для каждого парсера нужен тот самый пример (а иногда и несколько), на основе которого паттерн выделяется. К счастью, многие магазины предоставляют их метой для поисковых систем, они выделяются у всех абсолютно одинаково, то есть нужен просто еще один скрипт

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


                1. Labunsky
                  01.12.2016 21:00
                  #9942086

                  А на логичный вопрос «почему не воспользоваться данными для поисковиков тогда» есть резонный ответ — там она почти всегда урезанная. То есть, одно фото товара вместо 10, например. Или цена только без/со скидкой. Или описание с многоточием после 136 символов. И так далее…


  1. Stronix
    01.12.2016 15:21
    #9941220
    -1

    Честно говоря, так и не понял смысла…

    Немного питона
    #!/usr/bin/env python3

import urllib.request
from lxml import etree

def main():
	u = urllib.request.urlopen("http://www.lamoda.ru/p/ug174awohj47/shoes-uggaustralia-uggi/")
	data = u.read()
	u.close()
	
	tree = etree.HTML(data)
	name = tree.xpath('//h1[@class="heading_m ii-product__title"]/text()')
	price = tree.xpath('//div[@class="ii-product__price-current"]/text()')
	manufacturer = tree.xpath('//a[@class="ii-product__brand-text ii-link_primary"]/text()')

	print(name[0])
	print(price[0])
	print(manufacturer[0])


if __name__ == '__main__':
	main()


    1. silenzushka
      01.12.2016 15:30
      #9941250

      Когда нужно парсить данные только нескольких магазинов, то Вы правы, можно делать самому. Ну и не будем лукавить, Вы понимаете суть задачи, а кто-то из разработчиков может не понимать, не хотеть разбираться или просто жалеть времени (не почасовая оплата у него).

      Кстати, у Вас паттенр вручную задан, а Product API сам находит паттерн, поэтому и работает с любым магазином без настройки. Это главное отличие. На рынке полно парсеров, которые нужно настраивать — разумеется это скучно.


    1. silenzushka
      01.12.2016 16:21
      #9941442

      Еще, смысл все-таки в постановке задачи. Если требуется парсить пару конкретных магазинов, то вариант сесть и написать скрипт с жёстко заданными шаблонами годится. Выше я уже написал что мы работаем с несколькими слоями данных а шаблоны и микроформаты всего лишь только 2 из 8.

      Удобство Product API именно в автоматическом получении данных из магазинов, о которых ни вы, ни система ничего раньше не знали и которые еще норовят дизайн менять периодически. Как только количество магазинов, которые нужно обрабатывать, увеличится со 100 до хотя бы 500, ручной вариант, предложенный Вами, уже не будет работать — мы это проходили.

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


  1. Akichi
    01.12.2016 16:09
    #9941388

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


    1. silenzushka
      01.12.2016 16:27
      #9941462

      Эти данные мы пока не собираем, но в курсе, что такие товары есть. Изначально была идея научиться парсить варианты товара, правда, понаблюдав за пользователями, мы обнаружили, что таких товаров добавляют меньше 2% и отложили на потом.


      1. Akichi
        01.12.2016 16:34
        #9941486

        Еще такой вопрос: в последнее время магазины применяют различные механизмы защиты цен. Я проверил одну такую ссылку через форму на сайте, и цена отобразилась неправильная (специально завышенная). Ваш сервис занимается обходом таких защит? Если да, то реализуется уникальное решение для конкретного сайта или систему подобному можно обучить?


        1. silenzushka
          01.12.2016 18:09
          #9941732

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


  1. Nikolay_Smeh
    01.12.2016 16:38
    #9941500

    Интересует порядок цен.


    1. silenzushka
      01.12.2016 18:00
      #9941712

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


  1. shurupkirov
    01.12.2016 16:50
    #9941538

    пока не увидел практической пользы, кроме создания сайтов арбитражников с товаром и партнерcкими ссылками на wildberries и lamoda.
    Через ваш api, увы, нельзя сравнить стоимость одного и того же товара на lamoda, wildberries и фирменного магазина


    1. silenzushka
      01.12.2016 17:56
      #9941708

      Для сайтов-витрин есть способ проще — XML выгрузки из партнёрских сетей. Быстрее и лучше работает. Вот только партнёрская программа есть у 1%-2% магазинов.

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

      Если Вы настроены серьезно, я могу написать в личку как минимум 9 кейсов, где Product API будет полезен и на которых Вы, как разработчик, сможете зарабатывать. Но только если Вы реально интересуетесь.


  1. Mendel
    01.12.2016 17:52
    #9941702

    Почему нет описаний и т.п.? Почему только один товар?
    Он неплохо берет мои магазины. Но это логично, ведь у меня и микроразметка, и нормальная семантическая HTML5. Но вот на разделе категории он засыпался. Почему? Взять кучу цен прямо из категории это самое разумное, чем дергать 100500 страниц товара. Тем более что инфы вы даете мизер, она есть и в категории. Конечно хорошо было бы чтобы еще и по пагинации ходили (опционально конечно), но в целом не ясная ситуация…
    ПС: и да, где цены? Одно дело если цена будет символическая, другое дело если соизмеримо с Яндекс.Маркетом (или другими АПИ которые можно и тыренные покупать у парсящих).


    1. silenzushka
      01.12.2016 18:26
      #9941768

      Вы описали краулер (ходит по URL), а у нас парсер (извлекает данные по URL). В интернете полно краулеров, которые могу начиная с главной пройти по всему дереву сайта, но вот URL для обработки они будут отправлять на Product API.

      Что касается описаний товара, то нам эти данные были не нужны. Если окажется, что они будут полезны пользователям API, то будем и их извлекать.


      1. peacemakerv
        02.12.2016 10:18
        #9942902

        Т.е. это нормальный вариант использования вашего API?: свой краулинг 100500 страниц с товарами какого-то одного магазина с 100500 запросами в Ваш API, сохранение данных в свою базу, и повторить для других магазинов?
        Или это прямой путь в Ваш черный список?


        1. silenzushka
          02.12.2016 14:06
          #9943382

          Вы описали вполне жизненный кейс использования API. Наша забота — взять данные о товаре по URL, сколько таких запросов и из каких магазинов будут эти URL дело Ваше. Мы парсим данные и следим, чтоб магазины не банили.

          Если будет спрос, то сделаем модификатор запроса не только на получение данных о товаре, но и отправку уведомления об изменении его цены в будущем на указанный callback_url.


          1. alekciy
            05.12.2016 12:25
            #9946410
            +1

            Как раз не жизненный кейс. Потому категории каталога и постраничку нужно так же парсить (сталкивался с вариантами где это была довольно нетривильная задача). А если у меня есть краулер, парсер, то зачем тогда Product API? При наличии такой инфраструктуры дописать парсинг товара уже не составляет труда. Работать нужно над полностью готовой услугой «скачать и мониторить весь каталог». Ваш клиент не разработчики. Кто в теме у того уже есть свои наработки. Ваш клиент — не технические спецы либо техспецы начального/среднего уровня которые в лучше случае кое как смогут интегрировать данные парсинга с некой другой системой.


            1. Mendel
              05.12.2016 15:12
              #9946746

              Забыли еще «у которых есть пул IP», чтобы не банили.
              Ведь для краулинга он нужен не меньше, а то и больше чем для разбора товаров.


            1. silenzushka
              05.12.2016 18:12
              #9947088
              -1

              Мы предоставляем API для тех, кто хочет делать сервисы для не технических специалистов. Кому нужно встроить функции парсинга данных или слежения за ценой в свои продукты. Мы не очередной парсер Яндекс.Маркета, у Product API проста функция по любому URL товара выдать информацию.

              Если заказчик просит обработать конкретный сайт, то шаблон лучшее решение. А если нужно с уверенностью получить данные с любого интернет-магазина в любой стране, то без нашей технологии не обойтись.


              1. peacemakerv
                06.12.2016 14:20
                #9948346

                А если куча запросов от вас к одному сайту — у вас проблема бана со стороны сайтов как-то решается?


                1. silenzushka
                  06.12.2016 14:36
                  #9948370

                  С блокировками, разумеется, разбираемся. Думаю, у нас один из самых надёжных способов.


  1. megawina
    02.12.2016 13:29
    #9943306

    Ребят, небольшая ошибка на странице API
    Prodcut API от Fetchee предоставляет стартапам и компаниям надёжный инструмент для парсинга товаров интернет-магазинов.


    1. silenzushka
      02.12.2016 13:29
      #9943308

      Спасибо! Поправили. После деплоя обновится.


  1. Mendel
    02.12.2016 14:12
    #9943400

    Вы описали краулер (ходит по URL), а у нас парсер (извлекает данные по URL). В интернете полно краулеров, которые могу начиная с главной пройти по всему дереву сайта, но вот URL для обработки они будут отправлять на Product API.

    Не-не-не. Никуда ходить не надо.
    Всёуже украдено до нас :)
    На странице категории УЖЕ ЕСТЬ информация по 20 товарам. Вы предлагаете мне скачивать эту страницу, брать из нее ссылки (как? все равно ведь разбирать страницу как-то). отбрасывать название товара, цену и т.п.
    А потом 20 раз дергать ваш АПИ, чтобы получить информацию которая и так была в категории (в 99.99% магазинов у категории инфы по товаром больше чем вы берете с карточки). Это не только мне глупо — это и вам глупо. В 20 раз больше запросов, больше трафа, больше банов IP, выше себестоимость, выше цена для клиента, меньше клиентов…
    Не хотите ходить по пагинации — не ходите.
    Но не разбирать категорию это просто глупо.
    Ну и вернуть ссылки которые предположительно являются пагинацией — тоже не сложно.
    Их буквально с пяток шаблонов.

    А так то без цен изучать смысла нет никакого.


    1. silenzushka
      02.12.2016 14:18
      #9943410

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


    1. peacemakerv
      02.12.2016 15:15
      #9943520

      А вот +1 тут, я тоже об этом упоминал в email.