Application Programming Interface Keys (or API’s) have an interesting relationship with EVE Online. They form a link between 3rd party applications and EVE, and are used so prolifically among the player-base it’s become almost second nature. Most alliances and corporations in EVE use API information to interview and track members of their groups in what has become the now infamous EVE recruiting process.
But player interactions with APIs don’t end there – there are applications for tracking character information, market information, killmails, POS tracking, skill training optimisers, fitting tools, contract tracking… The list is exhaustive, limited only by the imagination of the player base and the points of data that are available. In essence, almost everything that happens in Eve can be queried and tracked via an API. These API’s can then be used to power personal and 3rd party applications.
The development of the EVE API system stems all the way back to some of the earlier days of EVE. The the only system available, which not many will remember today, was known as ‘My EVE’ this eventually became ‘EVE Gate’.
The earliest Dev Blog concerning API’s was written by CCP Garthagk where plans for the API system (as we know and love it) were first laid down. They were then released in Revelations v2.0 not long after.
So came the birth of the Extensible Markup Language API (or XML API). On average the API server receives nearly 120,000 requests for data every second. When I queried Steve Ronuken (CSM X) on if he knew how much data that was his response was ‘Not a clue I’m afraid other than ‘shedloads”.
And that’s where APIs were for the next 3 years (with the exception of the occasional tweak and addition or subtraction of certain information). However, XML API’s have always been somewhat limited, in that they can be used to obtain information from EVE, but not the other-way. You can’t use XML API’s to send information to the client, and so began the next iteration, EVE Gate.
It was 2009, Facebook had just started making money after gaining its 500 millionth user and Social Media platforms were all the rage – Naturally CCP wanted one too! Thus, the concept of EVE Gate was born as written in a Dev Blog by CCP Greyscale. No, I’m serious, EVE Gate was meant to be your very own social media page for EVE online.
It did offer one interesting new feature, for the first time ever you could interact with people who also play the game without actually logging into the client itself. Which arguably it did, but in an E-mail client with address book kind of way. It was not the hip and friendly social media way originally envisioned and didn’t get used much. The mail editor isn’t even all that great to be honest.
My Corp Chatter Feed Apparently, not used in 678 days…
So, the EVE Gate experiment was a flop. But the promise of the ability to do things out of client was already in the minds of the player base. True to EVE player fashion, we didn’t forget about it either. Some began creating their own methods of accessing eve-mail which were ultimately still limited by the API technology available.
And so – the way we interacted with EVE didn’t really change much.
But 2009 was also the year CCP began working on Dust 514. Think what you may of the game itself, one of the very original design briefs was the crucial link to EVE Online. But EVE as it stood, other than a bit of a work around for mail and contacts in the EVE Gate, didn’t have any real way of receiving information. It could send you plenty, but it couldn’t receive anything and use that information in a way to effect the actual game. So something new had to be brought in.
While CCP had a number of options they eventually settled on a Carbon Representational State Transfer API, or CREST API. You can see CCP Seagull talk about CREST at Fanfest in 2012. (It starts at 52min)
The CREST API would in the end be the system that made the Dust / EVE link possible. It allowed the transfer of war information, killmails, market data, sovereignty, ISK, contracts, and items. Anything was potentially possible, one universe, one war.
Planetary District information in DUST 514 and EVE would share information via CREST
So it was 2012, 5 years since EVE’s first XML API launch. CCP was feverishly working away to get CREST ready for the end of the year so DUST and EVE would make their first connection.
This was also the time CCP FoxFour joined the company. CCP FoxFour had come from United Front Games after working on Sleeping Dogs. FoxFour has a few years experience in the games industry and he was also an avid EVE Player. By January 2013 the DUST / EVE CREST link finally went live. It was also the time CCP FoxFour was starting to familiarise himself with the API systems in EVE, having spent some time working on DUST 514.
I am a game designer not a programmer so picking it up was really me spending a whole lot of spare time poking things until I had a basic understanding of how it worked. I have been able to do a fair bit with it recently and as someone who used to, and still does, use the EVE API for my own tools this was both a lot of fun and scary. The API when I picked it up was seeing around 120k requests a second and breaking it meant breaking a lot of people’s things. – CCP Fox Four in his Developer Profile
If you ever had the opportunity to meet CCP FoxFour in person you will know his enthusiasm is simply boundless. He is one of the developers that you always see with a smile on their face.
CREST would also share information through other platforms such as this PS Vita
Sadly the Dust 514 dream started to falter as well, in the end it received mediocre reviews and only managed to make a profit as of March this year. Development stopped to nothing more than balance pass and a few new additional features here and there – but that is a story for another article.
Of course (if you haven’t watched the video above, then you should) CCP had identified that CREST had a lot more potential and so development continued until September 2014. Having developed a reputation with over a years worth of development experience tinkering with the API systems, CCP FoxFour was now leading the way and had started to formalise Third Developer tools with the creation of the EVE Developers website, which contains all sorts of useful resources. Along with the Single-Sign-On or SSO which allows the users of 3rd party applications to authenticate and log in with their characters via EVE Online the last of the main foundations to being rolling out CREST were ready, it was time to begin implementation.
For the next few months developers were given access to the SSO and access to a number of data endpoints. Websites like zkillboard were already using CREST to verify killmails.
By the end of November Market Data had become available. Unlike other sites that were either using API information from peoples accounts or the slightly dubious cache scraping method of updating its numbers: The CREST systems allowed the wholesale retrieval of live data for any number of items over any number of regions. It wasn’t long before examples of the in game market browser became available.
As of October the first major leap into allowing CREST to finally be able to Read/Write came as the ability to create and save fits to and from external applications became available for testing on the Singularity Test Server as explained by FoxFour in his blog here.
With over three years of development now completed CREST is now coming into its own.
In order to find out more I ventured onto the tweetfleet slack and poked my head into the devfleet channel, which for someone who is non technical it was a channel filled with what appeared to be an entirely different language.
I took some time to chat with CSM X representative Steve Ronuken (SR), who is most well known as the 3rd Party Developer CSM candidate and CCP FoxFour (FF) and asked them what was the main driver of CREST Development at the moment.
SR – Third party developers, mostly. Both internal to CCP (for their own projects) and outside. CCP understands that a rich third party ecosystem makes the game better.
FF – Their (3rd Party Developers) feedback is critical to the development of CREST and the XML API Along with ideas of what to do next they let me know what they need and simply by seeing what they are doing I can get an idea of what they need then there is all the testing they do for us and being able to talk to them in real time when they are having an issue is great and it helps build this really good strong relationship so that when something goes wrong on their end and I need to ask them to fix something or stop doing something we already have this really good relationship.
What was the biggest hurdle faced when developing CREST and getting it completely rolled out?
SR – The biggest hurdle has been the session issue.
Which is hard because of the potential impact on other areas of code? Like pulling a piece of spaghetti off a plate, you might just get the piece or the whole thing?
SR – Pretty much, you might end up with a ruined shirt. Quality Assurance would have to be really serious on it.
FF – The session issue is the only real issue remaining.
Any sneak peaks on what would be possible with CREST? What is the next goal?