Wargaming Public API
Wargaming.net Public API is a set of publicly available programming interfaces that provide access to Wargaming.net projects, including game content, player statistics, encyclopedia data and much 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 developers' competition, which we are going to hold in the very near future.
History of Public API Development
Before writing a section about the prerequisites for creating the Wargaming API, I decided to update my understanding of how public APIs basically developed 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 really interesting to me.
- February 7, 2000 - salesforce.com is launched, from the very first day offering users a fairly complete and functional API for their applications. 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, this was a necessary step, since a significant number of different applications, one way or another, pulled information from eBay pages.
- 2002 - Google launches the API to its search. The reasons are the same - developers are actively trying to use Google search tools 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. AltaVista, which was competing at that time with Google, however, was in no hurry to launch its API, “waiting for demand”, according to their technical director.
- 2003-2006 - social services begin to actively develop. API del.icio.us, Flickr, Facebook, Twitter, etc. appear.
- 2006 - the development of cloud services and, accordingly, their APIs: Amazon S3, Amazon EC2, etc.
- 2007 - Twilio launches, 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, the Foursquare API is launched.
- October 2010 - Instagram launch. Already in December, one of the third-party developers dismantled the API that the iPhone application used and released its unofficial Instagram API. In January 2011, Instagram closed the pirated API and announced that it was working on its own official API, which it released in February.
Thus, it turns out that at first the main driver for the development of the API were online trading platforms, then there was a lull. Further, the baton was picked up by the social services API, cloud and mobile APIs.
Since 2005, there has been a generally explosive increase in the number of various APIs. Here is a picture from ProgrammableWeb that confirms this:
Prerequisites for creating the Wargaming Public API
As you can see from the historical background in the previous section, often the reason for creating the API is the activity of third-party developers. They use the tools that are in order to obtain the data that interests them. However, they are not particularly stopped by the lack of an API. The web is organized so that you can always parse the target site and get the right information. Yes, uncomfortable. Yes, everything breaks as soon as the page layout has changed. Anyway, a lot of difficulties. But nonetheless.
Moreover, this picture does not suit not only third-party developers. A large number of requests scanning 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 user behavior, 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, a global map, encyclopedias, etc. Of course, site parsing began in an attempt to pull this data. And as soon as the World of Tanks Assistant came out, sufferers immediately attacked its API.
It was not difficult to draw a conclusion from all this: since information is needed by third-party developers, they will still get it. But in this case it is better to provide them with a public API. Managing it is much simpler, 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 quality applications appear around the game, which is important for its developer.
The internal interaction of the components behind the API
In order to understand how our API works, it’s useful to take a 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.
Our entire infrastructure around the games is built according to the service model, that is, the components are relatively independent and interact with each other through API sets. 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 II, Wargaming League, game portals, forums, encyclopedia, CPP and so on - only about 40 pieces);
- components are developed by different teams;
- components will not be released all together;
- full downtime when updating is not allowed.
That is, it is obvious that it is much easier to release a version of two or three components that are developed separately than to release a large system. In addition, the management of component development as small functional elements is simplified.
Our infrastructure has two main data streams: calling remote API methods and subscribing to events of another subsystem (game server, other components).
The component API is most often an 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 according to the AMQP protocol.
Events are also chased through RabbitMQ. An example of an event is the export of a player’s account status after it has been changed. In addition, for example, after each battle, the player’s tank dossier on which he played this battle is exported to MQ. This allows the game portal to display the latest player statistics whenever it comes to see it (well, almost). At the same time, an already loaded game server does not receive additional load.
If we move a little away from reality for the sake of simplicity of perception, we get this 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 APIs of other components it needs are located, and they interact directly, without any intermediate links.
About 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 perhaps that it is tied to a relatively large number of other services, that is, it is a kind of 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 to optimize response speed and load on the internal system. He also needs to check access rights and monitor the limits of calls from a particular application, collect statistics, etc. Since the API is public, a lot of code is written only for the sake of maintaining an external contract and isolating changes to internal components and their APIs from external consumers.
I must say that with the introduction of the Public API, we have solved at least one of the urgent problems - the uncharacteristic load on our resources, which periodically spoiled our lives, has significantly decreased. Rather, it 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 relevant figures for RU-realm:
|API Method||Number of calls in 7 days|
|api.worldoftanks.ru/wot/tanks/stats||~ 7 360 000|
|Users logging into the developer’s office from the start of the program||63,750|
|Registered Application Keys||12 029|
In total, there are more than 200 active applications at the moment. The numbers are not the largest, but there are many worthy applications, and some, even by a very rough estimate, have spent quite a lot of time and effort. For instance:
- Knowledge Base for WoT mobile application;
- portal wot-news.com;
- numerous trunk, 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 ;
- game mods, the same XVM (where already without it).
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 for some reason is not enough. But for many of them, switching to an API would be more than appropriate.
By the way, Wargaming is not against the idea that good applications are monetized and bring revenue to their developers.
Developers Partner Program
The Public API is part of a much larger story than just an API to our data and a website with documentation. It is also a tool for collecting feedback and developer support.
As part of this project, we would also like to bring together game mod developers and try to establish a constructive dialogue with them. If the data API now covers many of the needs of developers, then for modders life is much more complicated. I hope we can make it a little nicer. Actually, this is why the whole project is called the Wargaming Developers Partner Program, and not just the Public API.
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 a lot of ambitious guys in the community and they can afford to complete projects that implement ideas that Wargaming still does not see or whose implementation is delayed. It can be anything: integration with different platforms and interfaces of other services, crazy 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 certainly present unique and original projects to our multi-million audience.
We will talk about the details of the competition, prize categories, prize pool and registration procedure next week.
Follow the news!