Source: http://habrahabr.ru/company/wargaming/blog/229475/

Hello everyone,

today, we are going to have a look at an article, published on the Wargaming blog, about the public API system. Now, I am not a programmer, so excuse me if something gets mistranslated – I think it’s interesting for quite a few folks (especially some modders and web programmers) so it would be a shame not to attempt to translate it, but if I make a mistake somewhere, feel free to correct me. Here goes.

Wargaming.net Public API is a set of public programmer interfaces, providing access to Wargaming projects, including the game content, player statistics, data from encyclopedias and many other things. In this article, we will talk about the background of the API, how the interaction of our internal components looks and about how the API is built and how it works and a bit about the developer contest we are planning to do in the near future.

History of public API development

Before I write something about the WG API background, I decided to check out a bit on how the public API was developed in the past, so I could look for corellations in API development and evaluate it as a phenomenon. I made a short summary for myself, as this info turned out to be really interesting.

- 7.2.2000 – salesform.com starts, providing its users with a quite complete and functional API for its applications from day one. These guys were practically the first ones, who offered the software-as-a-service format to their users
- 20.11.2000 – eBay Application Program Interface is started as a part of the eBay Developers Program. It was a step that was de-facto forced by the fact that quite an amount of various applications mined data from eBay pages one way or another
- 2002 – Google starts their API for their search for the same reasons as above – the developers are actively trying to use the instrumental Google search in their applications and they are doing it as they can. There is a significant difference from the previous API providers in the fact that it’s not quite clear, how can such an API be monetized effectively. At that point, Altavista was a competitor to Google and they did not rush to release their API, reasoning that “we are waiting for the emeregence of a demand”, as mentioned by their technology director.
- 2003-2006 – active development and spread of social services started. API’s appear at del.icio.us, Flickr, Facebook, Twitter, etc.
- 29.6.2006 – API of Google Maps appears for the same reasons: the geo-data o Google Maps grew so quickly in popularity that their internal Java Script API was immediately dismantled by programmers to pieces, who then proceeded to use it as they saw fit.
- 2006 – development of cloud services and their API: Amazon S3, Amazon EC2 etc.
- 2007 – Twilio, API-as-a-product platform is released, providing its API users with the access to voice connection cloud service
- March 2009 – Foursquare is released and in November, after a funding round, API Foursquare is released as well
- October 2010 – Instagram starts. As soon as in December, one of their third party developers dismantled an API, used by their iPhone application and released his own unofficial Instagram API. In January 2011, Instagram blocked the pirate API and announced that they are working on an official API, that was released in February

This way it looks that in the beginning, the development driving factor behind the API’s were e-trading services, after which there was somewhat a pause in development. After that, it was picked up by social service API’s, cloud and mobile API’s. From 2005 onwards, there was an explosive increase in numbers of API’s, as confirmed by this picture

The background of Wargaming Public API creation

As was seen in the historical background of the previous part, it often happened that the API development impulse was the activity of third party developers. They are using the tools they have at their disposal in order to get the data they find interesting and during that, the lack of API doesn’t stop them. The web is organized so that it is always possible to parse the target site and to recieve the piece of information you need. Yes, it is inconvenient. Yes, everything gets broken as soon as the page layout changes. And yes, there are a lot of difficulties. Nonetheless, it’s possible.

The thing described above is not unsatisfactory only for third party developers. A large amount of requests, scanning the site for information, can create a serious load on the server to the point of completely shutting the site down. Especially when you consider that the application you are using is usually optimized for the user’s behavior and not the one of the crawler.

In this sense, Wargaming is not different. When the “tanks” became popular, a demand for infomation for player profiles, clan profiles, statistics, ratings, global maps, tank data etc. immediately appeared. Of course, the parsing of sites started in order to pull the data out. And as soon as the World of Tanks Assistant came out, its API was immediately a target of interest.

It was easy to make a conclusion out of all that: once the third party developers needs some info, they will get it no matter what anyway. That’s why it’s better in such a case to give them public API. It’s easier to handle and it provides more stable, easier to use and reliable tool to the developers and for us, it at least allows us to save traffic and to reduce the server load due to the optimized algorithms. Apart from that, with public API, the applications get more functions, they get more stable and reliable. The end users are happy and the game also gets more quality applications, which in turn is important for the game developer.

Next time – “internal interactions of the components behind the API”…