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 мы приготовили отличный призовой фонд; кроме того, уникальные и оригинальные проекты мы обязательно представим нашей многомиллионной аудитории.
О подробностях конкурса, призовых категориях, призовом фонде и порядке регистрации мы расскажем уже на следующей неделе.
Следите за новостями!
