The Riot Games API: Goals and Design

Hello all, Leigh Estes, aka RiotSchmick, here. I’m a software engineer at Riot Games, working in the Service Availability initiative. Today I’d like to discuss the beginnings of one of the products our initiative owns, the public Riot Games API, including why we built it and how we think we’re doing in light of those goals.

During the first several years after the launch of League of Legends, fan sites and stats services obtained data by scraping Riot websites or imitating client traffic to Riot servers. Inefficient scraping methods increased the load on our server platform, which in turn put live services at risk. This sort of traffic caused a degradation of players’ experience. We needed to find a solution, and a public API seemed like the right one.

The argument for open APIs, like that for open source software, has largely been had and won. Thoughtful public APIs encourage innovation and increase engagement with specific pieces of technology. Programs run by the likes of Facebook, Twitter, Google, and Netflix have extended the reach of their products and fostered healthy developer ecosystems. The games industry is no stranger to this concept, with studios like Blizzard, Valve, and CCP offering open APIs for their games or platforms.

Inspired by the success of APIs from other companies and looking to address the effect of scraping on our players, Riot Games released our own developer API program in late 2013. This sort of public web API differs from client-side APIs used in the game modding community. These server-side APIs largely provide game and player data and tend not to directly change game play. The Riot Games API allows developers to access match history data, ranked leagues stats, champion and item info, and much more. Using this data, the League of Legends community has created many useful tools and websites, ranging from stats sites like OP.GG to sites that provide players with supplementary features like replay.gg.

When starting the API program, we had several specific goals:

• Protect our live services by offering legitimate and regulated access to League of Legends data

• Guide third-party developers to make applications that are aligned with our values and address player needs

• Facilitate data sharing internally within Riot

Achieving Our Goals

We launched two teams to examine and tackle these three goals.  The Developer Relations team is responsible for fostering Riot’s relationship with the third-party developer community and communicating policies and values as they pertain to the public API. The Developer Platform team is responsible for building all of the infrastructure that makes the public API possible. These teams work together to provide the technology and features needed to achieve our goals.

Here’s how this manifests in our goals:

Protect our live services by offering legitimate and regulated access to League of Legends data

We needed to provide sanctioned public endpoints through which traffic could be authorized and rate-limited via API keys. Initially, we looked into leveraging one of the many existing API management platforms. We did spikes to evaluate apiGrove and Repose. There were pros and cons to each, but ultimately, we decided to build and host our own public API instead of leveraging an existing solution.  There were several reasons for this approach, one of which is Riot's unique global footprint - there is no single out of the box solution that would work for all the regions and partners for which our technology needs to be deployed and integrated. As the program evolved and we learned more about our myriad of potential use cases, we wanted high levels of flexibility and customization, rather than being locked into a given framework. Of course, we utilized existing technology where it made sense as part of our homegrown solution. First, we leveraged open source software, like the Zuul proxy server and other projects developed by Netflix including archaius, ribbon, hystrix, and eureka. Our Zuul filters and core functionality are written in Java and Groovy and are run in Jetty. In addition, we used Amazon’s AWS offerings for quick and easy access to all aspects of our desired stack, including Redis, MySQL, UNIX servers, load balancers, etc., as well as built-in horizontal scaling. We have been able to scale up our architecture as needed over the years and currently service hundreds of millions of calls a day. In my next blog post, I’ll deep dive into that architecture.

Guide  third-party developers to make applications that are aligned with our values and address player needs

We wanted to provide a public developer portal to facilitate interaction and ongoing conversation with  third-party developers regarding Riot’s values and policies. We require community developers to submit their application for review in the developer portal prior to granting a production-certified API key—this helps to ensure that community creations promote healthy, non-toxic player experiences while preserving the competitive integrity of League of Legends. Curating the application submissions can be tricky and cumbersome, but we've found the dialog to be valuable as it allows us to better understand developer needs while at the same time sharing and reinforcing our values. Once submitted, community developers can use the developer portal to interact with our Developer Relations team regarding their application’s status. There are also specialized forums where community developers can interact with each other, as well as with the Developer Relations and Developer Platform teams. In addition, there is Swagger-style documentation for all currently available APIs and links to various articles on how to get started with and use the API. To date, around 4,000 developers have submitted applications and about 900  projects have an approved production API key. In order to simplify development by leveraging an existing MVC framework, we built the developer portal as a Grails application written in Java and Groovy that runs in Tomcat, and utilizes Bootstrap for the front-end.

Facilitate data sharing internally to Riot

We began circulating the developer portal internally and encouraged teams to take advantage of its offerings. Most public API programs are focused on external collaboration, but we've found plenty of cases in which collaboration between developers and teams internally at Riot has been improved. Simply having a reliable registry of available APIs in the developer portal helps Riot software engineers onboard more quickly and in some cases has started conversations about accessing data that a team may not have otherwise known was available. The edge layer makes it possible for more teams to easily gain access to those APIs.  Our global offices, in particular, have taken advantage of the public API, using it as a fast, reliable way to access player data without needing to navigate internal technical hurdles and team structures. Programs like Guilds in Russia and Battlegrounds in Europe are powered in part by our public API.

We've seen great success in reaching our original goals.  Third-party developers have embraced and adopted the API as the de facto standard for obtaining Leagues of Legends data, and scraping is no longer an issue for our live services. Perhaps the best result of our API program is what the technology has unlocked. A consistent API platform solves many of the common needs for the micro-service development we are increasingly adopting at Riot. We can solve scaling, rate limiting, load balancing and many security concerns in one universal layer of the architecture. Our API platform is positioned to serve as a smart edge layer not only for player-facing League of Legends traffic, but for any services we build at Riot, both now and in the future.

Engaging the Developer Community

While the API has reaped benefits internal to Riot, enabling the community to build solutions for our players was a key goal as well. Thus, we feel it is important to engage and foster the developer community. To that end, we announced our first API challenge in March of 2015 with a prompt of utilizing game data from the Ultra Rapid Fire game mode. We were surprised and delighted by the response—developers from multiple regions submitted over 100 completed entries. The majority were submitted by developers that opted to “duo queue” on their projects, many of whom paired up via interaction on the developer forums. All of the entries impressed us, and the winners were hard to narrow down.

We felt the first API challenge was a total success in terms of creativity, engagement, and participation, so in August we announced our second API challenge, this time with three different categories, including utilizing the game data from Black Market Brawlers matches, utilizing game data from before and after AP item changes, and utilizing item set documentation. This time, we had over 300 entries with the majority of submissions from pairs of collaborating developers. We chose winners from each category. While these challenges do award prizes, the ultimate goal is community engagement, collaboration, and opportunity to learn from each other.

In November 2015, we hosted an on-site hackathon. Invitees included API challenge winners and runners-up, as well as some key members of the developer community. The attendees were split into teams and had a little under two days to create a project. At the conclusion of the event, the attendees had a chance to show off their projects to Rioters at an internal science fair. Many of the projects were based on the API, but some teams chose to create projects that utilized the client, for example, an in-game auto-caster and a minigame based on in-game assets. All the attendees enjoyed the event and retained rights to their projects after the hackathon was over.  We hope to continue hosting challenges and hackathons in the future, so that we can continue to learn and grow with the developer community.

Thanks for reading! If you have any comments or questions I certainly invite you to post them below. I’ll be back in the near future to discuss the technical architecture that powers our API platform.

For more information, check out the rest of this series:

Part I: Goals and Design (this article)
Part II: Deep Dive
Part III: Fulfilling Zuul’s Destiny
Part IV: Transforms