Компания
65,79
рейтинг
11 июля 2014 в 11:08

Разработка → Wargaming Public API

Wargaming Developers Partner Program
Wargaming.net Public API — набор общедоступных программных интерфейсов, которые предоставляют доступ к проектам Wargaming.net, включая игровой контент, статистику игроков, данные энциклопедии и многое другое.

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

История развития публичных API


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

  • 7 февраля 2000 года — запускается salesforce.com, с первого же дня предлагая пользователям достаточно полный и функциональный API к своим приложениям. Фактически, эти ребята были первыми, кто предложил формат software-as-a-service своим пользователям.
  • 20 ноября 2000 года — в рамках программы eBay Developers Program запускается eBay Application Program Interface. Де-факто, это был вынужденный шаг, так как значительное количество различных приложений, так или иначе вытаскивали информацию со страниц eBay.
  • 2002 год — Google запускает API к своему поиску. Причины те же — разработчики активно пытаются использовать инструментарий поиска Google в своих приложениях и делают это как получается. Значительным отличием от предыдущих провайдеров API является то, что не очень понятно, как такой API можно эффективно монетизировать. Конкурирующая на тот момент с Google AltaVista, однако, свой API запускать не спешит, «ждет появления спроса», по словам их технического директора.
  • 2003—2006 годы — начинают активно развиваться социальные сервисы. Появляются API del.icio.us, Flickr, Facebook, Twitter, etc.
  • 29 июня 2006 года — появление API Google Maps. Причины снова те же: геоданные Google Maps так быстро набрали популярность, что их внутренний JavaScript API немедленно разобрали по винтикам и начали использовать кому как нравится.
  • 2006 год — развитие облачных сервисов и, соотвественно, их API: Amazon S3, Amazon EC2 и т.д.
  • 2007 год — запускается Twilio, API-as-a-product платформа, предоставляющая своим пользователям API к облачному сервису голосовой связи.
  • Март 2009 года — запускается Foursquare, а уже в ноябре после раунда финансирования запускается и API Foursquare.
  • Октябрь 2010 года — запуск Instagram. Уже в декабре один из сторонних разработчиков разобрал API, которым пользовалось iPhone-приложение, и выпустил свой неофициальный Instagram API. В январе 2011 года Instagram закрыл пиратский API и объявил, что работает над собственным официальным API, который и выпустил в феврале.



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

Года эдак с 2005 наблюдался вообще взрывообразный рост количества всевозможных API. Вот картинка с ProgrammableWeb, это подтверждающая:



Предпосылки создания Wargaming Public API


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

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

Собственно, в этом плане Wargaming ничем не отличается — как только «танки» стали популярными, сразу же возник спрос на информацию по профилям игроков, кланам, статистике, рейтингам, глобальной карте, энциклопедиям и т.д. Разумеется, начался парсинг сайтов в попытках вытащить эти данные. А как только вышел World of Tanks Assistant, на его API немедленно набросились страждущие.

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

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

Внутреннее взаимодействие компонентов «позади» API


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

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

  • даже если что-то падает, все остальное должно работать;
  • компонентов много (сервис аутентификации, OpenID-провайдер, система рейтингов, клановые сервисы, Мировая Война, Wargaming League, игровые порталы, форумы, энциклопедия, ЦПП и так далее — всего около 40 штук);
  • компоненты разрабатываются разными командами;
  • компоненты не релизятся все вместе;
  • полный простой системы при обновлении недопустим.

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

Принципы взаимодействия


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

API компонента чаще всего представляет собой HTTP REST API. Вызов API может возвращать ответ как синхронно, так и асинхронно. Для асинхронных ответов используется Message Broker (RabbitMQ в нашем случае) по протоколу AMQP.

События также гоняются через RabbitMQ. Примером события может служить экспорт состояния аккаунта игрока после его изменения. Кроме того, например, после каждого боя в MQ экспортируется досье танка игрока, на котором он этот бой играл. Это позволяет игровому порталу показывать актуальную статистику игрока, когда бы он ни зашел ее посмотреть (ну, почти). При этом и без того загруженный игровой сервер не получает дополнительной нагрузки.

Если чуть-чуть отойти от реальности ради простоты восприятия, то получится вот такая картинка, описывающая принципы взаимодействия наших компонентов в вебе:

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

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

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

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

Немного статистики


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

Вот немного актуальных цифр для RU-реалма:
Метод API Кол-во вызовов за 7 дней
api.worldoftanks.ru/wot/account/tanks ~13 800 000
api.worldoftanks.ru/wot/account/info ~13 100 000
api.worldoftanks.ru/wot/tanks/stats ~7 360 000
api.worldoftanks.ru/wot/ratings/accounts ~5 800 000
api.worldoftanks.ru/wot/clan/info ~3 800 000
Пользователи, заходившие в кабинет разработчика со старта программы 63 750
Зарегистрированные ключи приложений 12 029

Приложения


Всего активных на текущий момент приложений — более 200. Цифры не самые большие, но среди приложений много достойных, а на некоторые, даже по очень грубой оценке, потрачено порядочно времени и усилий. Например:

  • мобильное приложение «База знаний для WoT»;
  • портал wot-news.com;
  • многочисленные стволо-, олене- и прочите нубометры;
  • клановые сайты;
  • стат-сайты: vbaddict.com, wotinfo.net, wotlabs.net и многие другие;
  • клановые сайты и сайты с информацией о Глобальной карте;
  • игровые моды, тот же XVM (куда уж без него).

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

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

Developers Partner Program


Public API — часть значительно большей истории, чем просто API к нашим данным и сайт с документацией. Это еще и инструмент сбора обратной связи и поддержки разработчиков.

В рамках этого проекта мы также хотели бы собрать разработчиков игровых модов и попытаться наладить с ними конструктивный диалог. Если API к данным сейчас закрывает многие потребности разработчиков, то у мододелов жизнь сильно сложнее. Надеюсь, нам удастся сделать ее немного приятнее. Собственно, именно поэтому весь проект целиком называется Wargaming Developers Partner Program, а не просто Public API.

Конкурс


Сейчас мы готовы перейти к следующему этапу поддержки проекта и взаимодействия с игровым сообществом — открытому конкурсу для разработчиков.

Wargaming Developers Contest будет направлен на поддержку разработчиков игровых модов, приложений и околоигровых сервисов. Мы уверены, что в сообществе много амбициозных ребят и им по силам сделать законченные проекты, реализующие идеи, которые Wargaming еще не видит или реализация которых откладывается в долгий ящик. Это может быть что угодно: интеграция с разными платформами и интерфейсами других сервисов, по-хорошему безумные пользовательские интерфейсы, концепция второго игрового экрана и многое другое.

Для всего этого в рамках Wargaming Developers Contest мы приготовили отличный призовой фонд; кроме того, уникальные и оригинальные проекты мы обязательно представим нашей многомиллионной аудитории.

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

Следите за новостями!
Автор: @mephius

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

  • +5
    Долго ждал ваше Api. Но буквально на прошлой неделе реализовывал регистрацию через ваш OpenID и натолкнулся на очень большое неудобство когда открываешь страницу вашего сервиса, где пользователь мог бы авторизоваться, она рассчитана под полноэкранный разворот, а не на небольшое окошко в итоге получается такая жуть. Сделайте это шаблон адаптивным, что странно страницу с разрешениями для доступа после авторизации вы доработали.
    • 0
      Плюсую! Вроде как есть display=popup, а толку от него если там полный размер :)
    • +1
      Сейчас упрощенная страница покажется для мобильных устройств (параметр display работает только если устройство определится как мобильное).
      Я сейчас посмотрел в трекере — есть тикет по поводу того, чтобы и для обычных браузеров можно было показать короткую форму в попапе, но он не особенно высоко приоритезирован.

      Полагаю, что если апвоутнуть задачу через форум, ЦПП (ну или прямо здесь), то приоритет вполне может смениться. В каждую версию попадает 3-4 задачи по баг-репортам или реквестам от пользователей, так что все вполне реально.
    • 0
      У команды WG OpenID есть и доводы против, кстати:
      С запуском OpenID провайдера столкнулись с тем, что появилось довольно много сайтов, которые спуфили аутентификацию варгейминга, предлагая во фрейме или в попапе без адресной строки ввести логин с паролем в форму, похожую на форму варгейминга. А поскольку угон аккантов — довольно больная тема для WG (по крайней мере была), то логин в окошках и фреймах сейчас не приветствуется.
      • 0
        Не понял связи с неудобным шаблоном страницы для авторизации.

        И я думаю такие проблемы есть и более популярных провайдеров ОpenID как Вконтакте или Facebook и они их как то решают другими способами кроме неудобного шаблона для страницы.
        • 0
          Смысл в том, чтобы пользователь всегда мог посмотреть в адресную строку и увидеть, что он на домене варгейминга, ну или убедиться в обратном.

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

            А то когда показываешь пользователям большие окна и они еще начинают жить своей жизнью это пугает их, тогда как небольшое окно с формочкой юзером воспринимается нормально, привыкли к этому уже не пугается.
            • +3
              И все-таки рекомендуемый метод — редирект. OpenID вполне позволяет указать удобный return_to. Простите, но пользователи Вконтакте и Facebook не вкладывают в свои аккаунты деньги и воровство аккаунтов с целью продажи у этих сервисов не является проблемой, в отличии от ситуации с танковыми. В этом вопросе мы ориентируемся скорее на amazon, например.
  • 0
    > Это может быть что угодно: интеграция с разными платформами и интерфейсами других сервисов, по-хорошему безумные пользовательские интерфейсы, концепция второго игрового экрана и многое другое.

    Честно говоря игра заинтересовала не столько в качестве игрового процесса сколько в реализации API. (Потому что друзья иногда просят разработать утилитки для них). К сожалению API на данный момент объективно очень скудное.

    Что бы сделать тот же «второй игровой экран» нет многих элементарных вещей вроде онлайна друзей, чтение чата и т.д и т.п.
    Друг в клане попросил для их клана сделать возможность получить максимальный урон на технике — оказывается в игре это можно увидеть а в API этого нет. (Сошлись на том что сделаю средний урон на технике за минимальное N количество боев)
    Вот совсем недавно кто-то просил сделать отображение игроков в клане с техникой на которых у них есть три боевые отметки — тоже нет в API.

    Т.е. по сути API это хорошо — но лично мне приходится многим отказывать в их просьбе разработать для них что нибудь из за того что API на данный момент зачастую очень сильно отстает от того что есть в игре.
    • 0
      Можно смотреть опыт компании Samsung — они сделали ОС Bada, к нему сделали SDK на урезанном С++, где каждое приложение работало чуть ли не на уровне ядра и простая ошибка в приложении приводила к синему экрану смерти. А для того что бы элементарно скачать страницу с интернета приходилось писать несколько десятков строк кода и т.д. и т.п. На вопрос почему бы не сделать нормальный SDK на конференциях представители самсунг на полном серьезе без сарказма отвечали что при желании я могу сам выпустить SDK который решает множество элементарных вещей которые необходимы для разработки практически любого мобильного приложения. В итоге даже не смотря на серию конкурсов с бюджетом с миллионами долларов вроде этой платформа не взлетела.

      Но в любом случае лучше какой нибудь API чем его отсутствие. Но лично мое мнение — стоит доработать API, расширить его возможности, более оперативно открывать API для новых возможностей и разработчики потянутся и без всяких конкурсов.
      • 0
        Samsung — они сделали ОС Bada, к нему сделали SDK на урезанном С++, где каждое приложение работало чуть ли не на уровне ядра и простая ошибка в приложении приводила к синему экрану смерти.


        Вот этого как раз хотелось бы избежать. А для этого нужно чтобы моды работали в «песочнице», у которой есть описанный и понятный API, и которая, в том числе, помогала бы защищать игроков от недоброкачественных модов. Плюс такой подход сильно уменьшил бы вероятность конфликтов между модами и слом клиента при обновлении. Но это о-о-о-чень непросто сделать. Поэтому разговоры такие периодически всплывают, но пока только такими эпизодами все и ограничивается.
  • 0
    Пошукал немного, у всех танков price_xp равно 0… будет ли доступна в будущем эта информация?
    • 0
      Это в работе, но пока блокируется тем, что внутренние источники эту информацию не отдают. Т.е. да, в будущем будет доступна.
  • +3
    А вот эту фразу никто не видит что ли?
    В рамках этого проекта мы также хотели бы собрать разработчиков игровых модов и попытаться наладить с ними конструктивный диалог. Если API к данным сейчас закрывает многие потребности разработчиков, то у мододелов жизнь сильно сложнее. Надеюсь, нам удастся сделать ее немного приятнее.

    Просто сейчас мододелам действительно непросто и многие вещи делать сложно, вайна по этому поводу тоже немало. Так вот тут Варгейминг, считай, публично говорит о том, что хотел бы это изменить к лучшему. Пользуйтесь шансом, что ли.
    • 0
      Видим. Мне лично было бы увлекательнее сделать мод к игре нежели играть в эту игру. Например командир клана попросил для той же клановой тренировки что бы когда кто то стрельнул (без разрешения) над ним или в ушах отображался какой нибудь значек. (для того что бы не отвлекаться «кто стрелял» и т.п.). Или что бы над танком противника с минимум ХП/барбанщиками ставился знак фокуса (что бы новичкам было проще адаптироваться).

      По сути когда взялся за решение этой задачи я не смог найти никакой документации, ни тем более никаких API/SDK. Отказал другу в решении этих, вроде простых на первых взгляд, задач просто потому что объем работы который надо было проделать (т.е. потратить очень много времени для того что бы просто разбираться в структуре/где что где лежит и какой файл за что отвечатет) для решения оказался неподьемным по времени на данный момент.

      Прошу прощения что повторяюсь снова — но расширение API/SDK или документирование того что есть и как можно сделать привлекло бы значительно больше разработчиков.

      Но в любом случае спасибо за начинание — однозначно поддерживаю ее и жаль что могу поставить только один + статье. Просто много друзей играют в эту игру и периодически слышу от них просьбу что нибудь для них сделать в этой игре, и мне самому было бы интересно разнообразить те задачи что я ежедневно решаю.
      • 0
        Я выше ответил. Да, API/SDK было бы круто, здесь все это понимают. Но на это в текущих обстоятельствах потребуется столько усилий, что ни у кого пока руки не поднимаются.

        Если за время конкурса получится найти какой-то приемлемый для всех вариант решить эту проблему, то будет очень круто, я считаю.
  • 0
    Кстати, все хотел спросить, а почему авторизация OpenID, а не OAuth 2?
    • 0
      1. потому что аутентификация, а не авторизация
      2. была необходимость чтобы это работало просто у каждого, у кого есть openid, иначе вход через wargaming.net был бы только у тех, кто приделал кнопочку и интегрировался с нашим OAuth
  • 0
    Версионность API забыли или я невнимательно читал документацию?
    • 0
      Версий API как таковых нет, но все обратно-несовместимые изменения анонсируются за несколько месяцев до фактического изменения.
  • 0
    Делал несколько фич для клана, понравилось, что хотелось бы изменить\добавить:
    1. Кэширование ответа сервера. Если поставили высадку, то просчет хода скорее всего будет в течении часа, кэш успеет обновиться и игроки получат уведомления. Но если мы выиграли бой, то оповещение о следующем приходит когда мы уже его заканчиваем.
    2. Мы ставим высадку в разных временных зонах, как вычислить время боя я так и не понял. Оно всегда абсолютно разное(оно верно для текущей часовой зоны), как узнать через апи на какое количество часов надо корректировать время боя, непонятно.
    3. Хотелось бы собирать статистику по результатам мировой войны, кто участвовал\регулярно участвует в боях на ГК и сколько опыта\дамага сделал за бой. Что бы потом по результатам награждать\наказывать бойцов. Можно конечно парсить файл реплея(если дождался окончания боя, результат боя будет в реплее). Но через апи было бы гораздо удобнее
    • 0
      • Реквестировать фишки в API эффективнее всего через форум и ЦПП. Этот фидбэк действительно обрабатывается и, как я говорил выше, в релиз попадает 3-4 задачи по реквестам
      • Coderr делал клевый мод по ГК, возможно сможет подсказать что-то с использованием текущего API

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

Самое читаемое Разработка