API сервисы Mangomag.ru

от автора

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

Речь пойдет о самых основных API, без которых нашим клиентам пришлось бы учить китайский (и английский), и подбирать товары не в едином удобном интерфейсе, а оформлять заказы «кидая ссылки на товары», как это реализовано на некоторых других площадках.

Список API, о которых и пойдет речь:

1) Сервис перевода с китайского и английского на русский;
2) API Ebay;
3) API Amazon;
4) API Taobao;
5) API Aliexpress;
6) Сервис отслеживания посылок.

Начнем, пожалуй, с самого животрепещущего — сервиса перевода с китайского и английского на русский.

История ниже пойдет о вечной борьбе бобра с ослом, ну, вы поняли. )

Изначально к сайту было прикручено старое доброе Google Translate API, и, честно говоря, мы им были вполне довольны. Стабильная работа, адекватный перевод. Но все бесплатное хорошее, когда-нибудь заканчивается. Сервис стал платным, и, глядя на утекающие Корпорации Добра денежные знаки, мы поняли, что пришло время попробовать что-нибудь новое.
И тут кто-то вспомнил о Bing Translator API от Microsoft. Идея показалась не плохой, и хотя отзывы были неоднозначными, мы взялись за дело с энтузиазмом. Полные самые радостных предчувствий, мы начали тестировать новое API…

Что ж, в нашем случае вскрылась серьезная проблема: переводчик не распознавал теги, поэтому описания переводились лишь в том случае, если не использовалось избыточного форматирования или верстка была 100% валидной (что, как вы понимаете, в 99% не так).
После недолгого производственного совещания, была поставлена задача возвратиться в лоно Корпорации Добра, но как-нибудь изподвыверта, чтобы обошлось без круглых сумм.

Наши, закаленные в боях за юзабилити суровые программеры, не растерялись и предложили такой вариант: задействовать API Гугла только при переводе категорий и параметров сайтов аукциона, а описания переводить при помощи инструмента перевода для сайтов от того же Гугла (http://translate.google.com/manager/website/suggestions). Сказано — сделано. У главбуха наконец восстановился сон, ведь, если все получится, затраты существенно снизятся.

Но…

“После месяца тестов и танцев с бубном мы пришли к выводу, что эта штука не работает…” (с) Senior programmer в день дедлайна.

image

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

Не хотите ли заказать товары из категории “Избранные знания класс” или “Блок поле ключ ящик”? А “Вернуться назад хороший”? Минздрав предупреждает, не думайте слишком долго над тем, что это значит.

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

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

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

Ну, а следующая часть нашей статьи посвящается четырем столпам, на которых держится Mangomag.ru: API Amazon, API Ebay, API Taobao и API Aliexpress.

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

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

Так вот, получив добро на использование готовых API, наши, еще безбородые, программисты начали с двух американских сервисов (API Ebay и API Amazon). Видимо, проджект менеджер предчувствовал, что самую мякотку API Taobao и API Aliexpress лучше оставить на потом.

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

Удачно прикрутив и отладив Amazon, мы взялись за Ebay. Здесь программистам пришлось немного поколдовать, так как на этом этапе разработки мы пришли к выводу, что в административной части сайта необходимо разбивать заказы из разных магазинов на отдельные позиции. Связано это было с тем, что товары, отправляемые напрямую от продавцов, идут по другому списку, нежели те, что идут на склад в США. И наши менеджеры устали бесконечно проставлять пустые значения в случае прямого отправления.

Разработчики не подвели и, на волне энтузиазма, с запасом расширили возможности складской админки. Voila!, помимо решения проблемы (товары отправленные напрямую успешно проскакивали ненужные процессы), теперь в ней появилось еще пять шагов бизнес-процесса (в том числе загрузка фото для покупателя и расширенная система комментирования статусов заказа — фактически чат между персональным менеджером и покупателем).

Премия уже практически в руках программистов, все довольны и счастливы, но, вот, на горизонте замаячило API Taobao…

image

Учитывая предыдущий успех, к API Taobao мы пришли с полной уверенностью – сейчас подключим по-быстрому и можно брать отпуск. Но нас встретило два барьера: бюрократический и языковой.

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

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

Итак, документация переведена, зеленый коридор открыт, сервис прикручен и работает, американские API не отстают, разработчики уже откупорили бутылку шампанского…

Так, стоп, а где же обещанное API Aliexpress? Все верно. Его нет. Просто не существует, а значит впереди еще один месяц работы.

Первый вариант выглядел так: берем страницу при помощи curl и забираем все параметры в базу, кэшируем категории и опять же переводим “на лету” все параметры. Но тогда на сайте появляется новый раздел, где карточки оформлены иначе. Ну, где наша не пропадала, делаем новый парсер.

Сейчас механизм справляется практически со всеми разделами Aliexpress. Ну, а если появляется новая категория, то подстроить под неё уже существующий парсер гораздо проще, чем то решение «с нуля», которое было на ранних этапах.

В целом работа с площадкой Aliexpress оказалось простой, как все гениальное, так как у нас уже была одна площадка из Китая. В чем же простота? Да в том, что у Aliexpress есть прямая доставка. Да, она дольше, и пускай нельзя консолидировать посылки, но кому-то так проще – «заказать и забыть», пока заветная посылка не окажется в ближайшем почтамте. Да и нам, честно говоря, было на руку разгрузить склад в Китае.

Так что, и здесь все закончилось пусть не быстро, но зато хорошо.

И последняя наша история – легенда о сервисе отслеживания посылок.

image

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

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

Звучало неплохо, но, умудренный юзерфрендли интерфейсами, старший разработчик логично предположил, что в таком случае, высока вероятность того, что клиенту для простой проверки придется каждый раз вспоминать пароль. А это не есть гуд. Ведь тогда пользователь скорее воспользуется сайтами почты России или USPS напрямую.

Все впали в уныние и, воспользовавшись моментом, тот самый старший разработчик (по совместительству еще и тайный поклонник bootstrap-минимализма) настоял на доступности этого сервиса без регистрации любому пользователю. А саму концепцию он предложил реализовать в виде поисковика по двум сервисам сразу: Почты России и USPS.

Главный дизайнер, не отставая от своего коллеги, описал лаконичную визуализацию — строка и кнопка (прямо, как у ya.ru).

Этот вариант и был коллективно одобрен, но в процессе разработки появилась еще одна отличная идея — улучшить систему реперных точек статусов посылки, что и можно наблюдать на сайте сейчас. Клиент, проверяя статус своей посылки, видит прозрачные и понятные: «отправлено», «ожидает вручения» и «получено» — с датами и без лишних подробностей.

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

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

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

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

Именно поэтому, мы гордимся получившимся сервисом и надеемся, что вы оцените его как с технической точки зрения, так и с пользовательской.

Спасибо за внимание,
желаем удачных открытий!

ссылка на оригинал статьи http://habrahabr.ru/post/192756/