One API to Rule Them All

In the web development world, RESTish APIs (Application Programming Interface) have slowly become the de facto standard by which different computing systems are used to communicate with each other. While building an API for external use is nothing earth shattering and quite common in the programming world (we even have one for our collection), building an API for internal use has been a somewhat recent thing (unless you’re Amazon who’s has been doing this since 2002).

As we talked about in earlier blog posts, we are hard at work on the Bloomberg Connects project which aims to cross the divide between each visitor’s curiosity, and the knowledge of our museum staff.  As part of bringing these two together, we’ve been building software to help us. In technical terms, we have a mobile app for visitors to ask questions, and a dashboard app for audience engagement team to talk to our visitors.  For both apps, we are using the same internal API communicate across the two apps.

Why?  Internal APIs allow us to develop and iterate faster by giving us a clean separation of concerns from our back end data logic from our front end logic. What this means is that for our developers focused on the front end (the people who build the interface which our users interact with), instead of having to know how our whole system works, they only have to know how to interact with the API. Since the backend of a web development project can involve a ton of different things not necessarily important to the average front end developer, such as databases, web servers, caching, CDN, etc. this means a front end developer can focus on what they do best which is building a fantastic user experience.

A very high overview describing the relationship between our API and our mobile and dashboard applications.

Having an internal API also give us the flexibility to serve more than one consumer at a time.  This means our mobile app and our dashboard app can use the same API to get things done.  This is vastly superior to the more common approach in the past where each application would have to write its own data interfacing logic. This means that if a web app and a mobile app have some functionality that needs to be implemented in both, the exact same logic would need to be written in two different code bases. In the development and agile world we call this a violation of the DRY principle, which stands for “Don’t Repeat Yourself.”  DRY is one of the fundamental truths that guide our development process as it helps to protect us from buggy, hard to manage code.

Essentially the goal we are striving for is a “loose coupling” of our code base. To illustrate how important this is, imagine a world where everyone has to write their own programs to use a computer. This is obviously untenable as not everyone has the time, knowledge, and expertise to create their own programs. Instead we just download programs others have created. A computer program decouples the implementation details (code) from the actual use of the program. Programs themselves are already abstractions which hide many details of how they work to let a user do work in a higher level of abstraction. The creator of the program could modify the implementation of the program but keep the way the user interacts with the program the same and the user would not know the difference. That is loose coupling in practice.

Here at our technology department we’ve adopted the agile spirit 100% and are always looking for ways to improve upon what we’ve done in the past. Building APIs to power not just our external services, but also our internal services has been a fantastic step in that direction. We’re excited for the journey ahead and can’t wait to show you more!