No, APIs Are Not A Type Of Beer

…but you can use APIs to pull lots of data about beer into any application.

The term API, or application programming interface, is nothing new. In another life as a C++ developer, way back in 1998, I wrote to an API to render insurance claim images stored on a mainframe. I would “call” an API using a very specific requesting format, passing parameters to identify what I wanted to receive. It seemed amazing at the time — but I almost wish the technology world would come up with another name for what’s happening now. APIs today are an incredibly more powerful technology today than ever before.

A few things happened between 1998 and 2016 to make that so. For one, the Internet exploded into a global platform that businesses depend upon. Smartphones happened. Sensors happened. Software as a Service happened. ____ as a Service happened. What was once a connection between applications almost exclusively within the walls of a company is now a global network of data requesters and data responders. The common example given is Google Maps, which can be embedded in any website through its API. That example doesn’t really do justice to what’s really happening, so let’s take it a few steps further.

Post consumption model: Rather than a single API, the best applications today are calling a myriad of APIs, and only some are pulling visual representations like a Google map, getting HTML back from a request. The rest are using JSON or XML to pull structured data that doesn’t have display information, so that data can be rendered differently depending on the interface and purpose. This makes it possible that a banker at Wells Fargo can see data in one format (likely a standard monitor) while the mobile customer can get what they need either in a browser or in the bank’s app. Different consumers have different levels of security access and different consumption models, yet all can be handled through the same infrastructure without duplication of effort. APIs are allowing the construction of platform-agnostic interfaces and movement of consumption-agnostic data like never before.

Continuous deployment: Even applications themselves are changing, with the latest architectures designed around APIs rather than mashing up functionality in a single, monolithic app. A typical business now separates common functions like accounts receivable, accounts payable, HR, sales, etc. and uses API calls to bring data and functionality together when necessary. This design allows microservices that can be developed, fixed or improved in parallel with each other, by separate teams, in way that doesn’t require bringing down a monolithic application as it did in the past. The ability to constantly release updates because of this architecture is known as continuous deployment or DevOps. Here’s an example from an Uber-like business model:

Monetization: I use Map My Run as the means of tracking my fitness. The app is published by Under Armour, a clothing manufacturer, and doesn’t immediately bring to mind big data, but that’s precisely what they do. Pulling together anonymized fitness data from across the spectrum of hiking, running, biking and even dog walking, Under Armour is able to sell valuable data to marketers and create an ecosystems of those who want to understand the many individual patterns of the fitness market. Consider the value to a company like Purina of knowing when and where consumers walk their dogs.

Just like Under Armour, anyone with the means to collect data or perform data analytics can potentially monetize an API that serves content or a service for a fee. Weather Underground is another example of what most think of as a consumer-facing website, but one that provides a subscription, through its API for a host of organizations to pull weather data (past, current, future) into critical systems that manage logistics, irrigation, and even what clothing to display in a department store next weekend. The value of their API far exceeds weather.com’s public-facing model.

Headless” models: In the same way, commonly used content management systems (think: Wordpress, Joomla) are becoming outdated, and developers are moving to headless models (like built.io) where the point of content management is no longer to display anything in particular (think: a website), but instead to display everything in general. Data moves from an editing interface to its final destination, which could be a website, an app, an application or the Jumbotron at the ballpark without the creator or consumer being tied down to any one pattern or program. Content creation, edition, movement and consumption is entirely through APIs with no cumbersome application built to contain the user. Instead, the user is freed from restrictive design choices/real estate limits. This increases the velocity of business as well as providing remarkable future proofing.

Cloud versus on-premise: Cloud computing and all of its various versions depend completely on API technology. APIs manage the infrastructure of Platform as a Service (Paas), manage data flows into and out of the Cloud, and distribute functionality that allows the end user to be blissfully unaware of the systems (and locations) being touched as they use their phones, computers, sensors and now, even their cars. APIs provide a flexibility for our world to scale up or down as needed whether that’s in the Cloud (public or private) or on our own infrastructure.

Alternative applications: APIs are also an excellent way for developers to create alternative applications, often for an entirely new purpose. The explosion of apps for smart phones is a great example where creativity allows a relatively low level of effort to result in highly original ways of providing something valuable to users. Many governments have even gotten into this game by providing APIs that give access to datasets and analytics that can foster entirely new business models. An example would be Snips, which is using this “open data” to create a predictive modeling for smart cities. This allows predicting the risk of traffic accidents and the time between events at different locations.

To achieve these breakthroughs, APIs needed to move beyond simple calls and are now platform-driven so that they can be created, packaged, deployed, monitored, measured, secured, and updated using specialized software. This explains the rise of the API Software as a Service that has taken off in recent years, including our own Masheryplatform at TIBCO. Going back to our beer theme, TIBCO even hosts “APIs over IPAs” around the country.

APIs have moved from a way to access another system to the way to architect, build and continuously deploy systems. They’re at the heart of modern applications and are, quite literally, the keys to all of the kingdoms that drive the world.