Wargaming Public API

Wargaming.net Public API - a set of publicly available programming interfaces that provide access to Wargaming.net projects, including game content, player statistics, encyclopedia data, and more.

In this article we will talk about the prerequisites for creating a public API, organizing the interaction of our internal components, how the API is built and working, and a little about the developer competition, which we are going to hold in the very near future.

The history of the development of public API

Before writing the section on the prerequisites for creating the Wargaming API, I decided to slightly update my understanding of how public APIs developed in principle in order to look for correlations and evaluate the evolution of the API as a phenomenon. I will allow myself to make a brief squeeze, since this information seemed to me really interesting.

• February 7, 2000 - Salesforce.com starts, offering users a fairly complete and functional API to their applications from the very first day. In fact, these guys were the first to offer the software-as-a-service format to their users.
• November 20, 2000 - The eBay Application Program Interface is launched as part of the eBay Developers Program. De facto, it was a forced step, as a significant number of different applications somehow pulled information from eBay pages.
• 2002 - Google launches API to its search. The reasons are the same - the developers are actively trying to use the Google search toolkit in their applications and do it as it turns out. A significant difference from previous API providers is that it is not very clear how such an API can be effectively monetized. Competing at that time with Google AltaVista, however, it does not hurry to launch its API, “waiting for the appearance of demand,” according to their technical director.
• 2003—2006 - social services begin to actively develop. API del.icio.us, Flickr, Facebook, Twitter, etc. appear.
• June 29, 2006 - the appearance of the Google Maps API. The reasons are the same again: Google Maps geodata so quickly gained popularity that their internal JavaScript API was immediately dismantled into cogs and began to be used by someone you like.
• 2006 - development of cloud services and, accordingly, their API: Amazon S3, Amazon EC2, etc.
• 2007 - Twilio is launched, an API-as-a-product platform that provides its users with an API for a cloud-based voice service.
• March 2009 - Foursquare is launched, and already in November, after the round of financing, Foursquare API is launched.
• October 2010 - the launch of Instagram. Already in December, one of the third-party developers dismantled the API used by the iPhone application and released its unofficial Instagram API. In January 2011, Instagram closed the pirate API and announced that it was working on its own official API, which it released in February.

')
Thus, it turns out that, initially, the main drivers of API development were online trading platforms, then some lull came. Next, the baton was picked up by social services API, cloud and mobile APIs.

Years since 2005, there was generally an explosive growth in the number of various APIs. Here is a picture from ProgrammableWeb, this confirms:

Prerequisites for creating a Wargaming Public API

As can be seen from the historical reference in the previous section, often the reason for creating an API is the activity of third-party developers. They use the tools they have to get the data that interests them. In this case, they are not particularly stopped by the absence of the API. The web is organized in such a way that you can always parse the target site and get the necessary information. Yes, uncomfortable. Yes, everything breaks as soon as the page layout has changed. And indeed a lot of difficulties. But nonetheless.

Moreover, this picture does not suit not only third-party developers. A large number of requests that scan information from the site may well create a decent load on the server, or even completely "lay down" the site. Especially when you consider that the application is usually optimized for the behavior of the user, and not the crawler.

Actually, in this regard, Wargaming is no different - as soon as the "tanks" became popular, immediately there was a demand for information on player profiles, clans, statistics, ratings, global map, encyclopedias, etc. Of course, the parsing of sites began in an attempt to pull out this data. And as soon as World of Tanks Assistant was released, sufferers immediately pounced on its API.

It was easy to make a conclusion from all this: once the information is needed by third-party developers, they will still get it. But it is better in this case to provide them with a public API. It is much easier to manage it, it provides a more stable, convenient and reliable tool for developers, and at least it allows us to save traffic and reduce the load due to more optimized algorithms for such usage scenarios.

In addition, when there is a public API, applications are more functional, stable, reliable. End users are satisfied, and an even greater number of high-quality applications appear around the game, which is also important for its developer.

Internal interaction of components "behind" API

In order to understand how our API works, it is useful to look at how information flows are built inside, how data is delivered, its relevance, etc. Therefore, below - briefly about the internal organization of the interaction of components.

All our infrastructure around the games is built on the service model, that is, the components are relatively independent and interact with each other through sets of APIs. This is due to several factors:

• even if something falls, everything else should work;
• There are many components (authentication service, OpenID provider, rating system, clan services, World War, Wargaming League, game portals, forums, encyclopedia, TsP and so on - only about 40 pieces);
• components are developed by different teams;
• components are not released all together;
• full idle system when updating invalid.

That is, it is obvious that it is much easier to release a version of two or three components developed separately than to make a release of a large system. In addition, it simplifies the management of the development of components as small functional elements.

Principles of interaction

There are two main data streams in our infrastructure: a call to remote API methods and a subscription to events of another subsystem (game server, other components).

The component API is most often the HTTP REST API. An API call can return a response both synchronously and asynchronously. For asynchronous responses, Message Broker (RabbitMQ in our case) is used under the AMQP protocol.

Events also chase through RabbitMQ. An example of an event is the export of a player’s account status after a change. In addition, for example, after each battle, the player’s tank, on which he played this battle, is exported to MQ. This allows the game portal to show current player statistics whenever it comes to see it (well, almost). At the same time, the already loaded game server does not receive any additional load.

If we slightly deviate from reality for the sake of simplicity of perception, then we’ll get the following picture describing the principles of interaction of our components on the web:

Differences from reality are that, as such, we do not have a service bus. Each component clearly knows where the necessary APIs of other components are located, and they interact directly, without any intermediate links.

Approximately the same picture with the event bus - each component knows exactly how to connect to the broker in order to receive or publish certain messages.

The Public API is exactly the same component in this infrastructure as any other. Some difference is that it is tied to a relatively large number of other services, that is, it is such a facade to the entire ecosystem, if we talk about structural design patterns.

Of course, the Public API is not just a proxy service, it has its own additional logic, it can cache and store some data sets in order to optimize the response speed and the load on the internal system. It also needs to check access rights and monitor the limits of requests from an application, collect statistics, etc. Since the API is public, a lot of code is written only for the sake of preserving the external contract and isolating changes to internal components and their API from external consumers.

Some statistics

It must be said that with the introduction of the Public API at least one of the pressing problems we decided - the uncharacteristic load on our resources, which periodically badly spoiled our lives, was significantly reduced. Rather, flowed into the API, where it is much easier to control and ensure the reliability of both the system as a whole and the service for third-party developers.

Here are some actual numbers for the RU-realm:

API method	Number of calls in 7 days
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

Users who logged into the developer’s office from the start of the program	63 750
Registered Application Keys	12,029

Applications

There are more than 200 applications that are currently active. The numbers are not the biggest, but among the applications there are many worthy ones, and some, even by a very rough estimate, have spent a fair amount of time and effort. For example:

• WoT Knowledge Base mobile app;
• portal wot-news.com;
• numerous stem-, deer- and read nubometers;
• clan sites;
• stat sites: vbaddict.com, wotinfo.net, wotlabs.net and many others;
• clan sites and sites with information about the Global Map ;
• gaming fashion, the same XVM (so far without him).

Not all third-party sites and applications now use the API. For example, those that appeared before the release of the affiliate program, or those for whom the current set of interfaces is not enough for some reason. But for many of them, switching to an API would be more than appropriate.

By the way, Wargaming does not mind that good applications are monetized and bring income to their developers.

Developers Partner Program

The Public API is part of a much larger story than just our data API and the documentation site. It is also a tool for gathering feedback and supporting developers.

As part of this project, we would also like to gather game game developers and try to establish a constructive dialogue with them. If the data API now covers many of the developers' needs, then modders have a much harder life. I hope we can make it a little nicer. Actually, this is why the entire project is entirely called the Wargaming Developers Partner Program, and not just the Public API.

Competition

Now we are ready to move on to the next stage of project support and interaction with the gaming community - an open competition for developers.

Wargaming Developers Contest will be aimed at supporting developers of game mods, applications, and near-game services. We are sure that there are many ambitious guys in the community and they are able to make finished projects that implement ideas that Wargaming doesn’t see yet or whose implementation is being put on hold. It can be anything: integration with different platforms and interfaces of other services, in a good way insane user interfaces, the concept of a second game screen and much more.

For all this, as part of the Wargaming Developers Contest, we have prepared an excellent prize pool; In addition, we will definitely present unique and original projects to our multimillion audience.

We will tell you about the details of the competition, prize categories, prize fund and registration procedure next week.

Follow the news!