"We want a team to decide they need an API, build it, and launch it the same day it's finished."
How do you use APIs at Motley Fool?
Our APIs are mostly for internal use, but we also have some that are public facing and for partners. A good example of the latter is our stock quote API, which makes stock information available to websites around the world. We essentially provide a white label stock quote service through an API.
What technical needs were you addressing with APIs?
In the past, Motley Fool was mostly a technical "mono culture" internally – all our code was in .NET and C#, and we shared services directly in code. We didn't have to worry about services from other systems. But in the last year and a half, we've been branching out to more platforms and languages like Python, Django and PHP. All of these systems needed to be unified so they could efficiently share a common repository of Web services. So we needed to take existing applications that we've had forever in .NET and make those available to other platforms through simple APIs.
What public APIs do you offer?
We have a publicly available API of our community stock analyst simulation, CAPS. This API allows members of the simulation to dig deeper into their personal statistics and create profile or screening widgets to find new investing ideas and similar investors to follow. While we haven’t yet rolled out some portions of the API, including ones related to user authentication and interaction, by using the public APIs we've been able to access our community intelligence data easily in several new systems without needing to refactor our old code.
How has your API strategy evolved?
We had some core data and apps that enable users to manage their stocks, and about two years ago, we closed a deal to post stock data on AOL stock-related sites. Our entire technical architecture was refocused on that initiative, exposing data APIs to AOL. That got us thinking about how we could leverage APIs internally. We don't yet have a ton of APIs and partners, and we're still thinking about how to use them to help integrate different technology stacks together.
We tend to add APIs as one team needs data that exists in another team's domain. We haven't gotten to the point where we build APIs first – but I expect we'll get there.
How do you work with Apigee?
Initially, we worked with Apigee every time we launched a new API. This has changed recently, when we migrated to the newest version of the Apigee API platform. The latest version of Apigee is a lot more self-service, and this is exactly what we want. We want a team to decide they need an API, build it and launch it the same day it's finished. We have launched a couple of APIs with the new self-service Apigee, and it's working well.
What do you see as the technical benefits of using APIs?
APIs let us use the right platform for the job. In the past, if you needed access to our stuff, you needed a .NET stack. By making our core business services available through APIs, we've expanded the possibilities as a tech team to make platform decisions. It gives us new flexibility.
What challenges have you experienced with your APIs?
We have several different teams working on building APIs, and having a good standard for what APIs are going to look like can be difficult. We have a standard defined, but we haven't done a great job of communicating it internally. We need to do a better job of standardizing so that our APIs start looking more similar than dissimilar, and it's hard to get people to use the same sort of patterns. But overall, we haven't had a lot of problems. It's been pretty smooth.
What is your vision for your API program moving forward?
We see ourselves using APIs more and more consistently across applications. We recently deployed a Web application to Amazon Web Services that uses Apigee for all the data services. It has a clean UI logic and a very nice architecture that we'd like to see more of our projects utilize.