The API economy is growing up. APIs are no longer a toy or gimmick for companies to show off. They’re complete business resources and, oftentimes, products in and of themselves.

As James Higginbotham puts it in the intro to his book A Practical Guide to API Design, co-written with Dr. Keith Casey Jr., “If you read the tech press, you probably have the feeling that everyone knows they need an API, although most aren’t really sure what it is. They treat APIs like another checkbox, like “Web 2.0” was a few years ago or as mobile apps were recently.”

Considering the amount of data users process on a daily basis, it could be argued that APIs are essential to business success as we continue to hurtle towards a data-driven society. That means not only understanding the current state of API design but also where we’re heading in the industry.

APIs, Microservices, Serverless: The Shape Of Things To Come

James Higginbotham’s presentation from the Austin API Summit covered the present reality of the API industry. We need to understand the current state of the API economy if we’re to understand which way it’s headed.

The API Landscape

Higginbotham leads with a quote from Roy Fielding, the originator of the REST language.

“The Rest Interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.” – Roy Fielding

What exactly do Higginbotham and Fielding mean by “coarse-grained” vs. “fine-grained” communication?

Coarse-Grained Vs. Fine-Grained Communication

As we’ve covered on the blog, granularity is how a system’s broken down into smaller components. Coarse-grained communication has a lesser number of larger components. Fine-grained communication breaks those pieces down into smaller, more digestible chunks.

For example, a coarse-grained communication module might be labeled “Accounts.” This would store the customer name, address, opening date, account balance, and last change date. Those sub-divisions would be examples of fine-grained communication.

Coarse-grained communication can be large, unwieldy, and difficult to implement. Fine-grained communication offers the ability to sort data at a more usable, useful level. This will become increasingly more important as we move closer towards a truly data-driven economy.

It’s also an example of how the future of API design will involve integration and collaboration rather than operating in a vacuum.

The Enterprise API Platform Journey

APIS, Microservices, Serverless: The State Of Things To Come illustrates many of these principles using a fictional eCommerce platform as an example.

Most enterprise-level APIs begin as fairly simple. Often, enterprises are looking to develop a mobile or web app. They might create a single API to fuel their apps. These apps start to get some traction in the marketplace, leading them to hire more developers, which slows the development process.

At this point, enterprises often start to incorporate microservices. Microservices are a way to reduce coordination, by breaking things down into smaller, more deployable services as part of the larger architecture.

Higginbotham focuses on the interface and dependencies surrounding microservices.

Interfaces include:

• Queries
• Commands
• Events published

Dependencies are made up of:

• Service dependencies
• Event subscriptions

Thinking along these lines helps developers to break out of the CRUD pattern (Create, Read, Update, Delete), allowing other developers to make use of the API more quickly and effectively.

Serverless: Rapid API Development and Event Processing

Serverless is a recent trend in API development that allows APIs to be as streamlined as efficient as possible. Higginbotham offers the example of GitHub Actions to demonstrate how teams don’t need to host their own functions, rather, much can be automated from a single a Git push.

He then details how an API might be designed and built in a business environment. Once things are running smoothly, the C-suite often wants the API to become marketable, with the ability to upsell and cross-sell the services. This works towards the goal of increasing the sale amount of each transaction through the website.

This requires digging into the data on a more granular level, allowing more actionable insights into the API. At this stage, the question of data management and permissions becomes more important, and data pipelines start to come into play. Higginbotham details two kinds of data pipelines.

ETL

ETL stands for ‘Extract, Transform, Load.’ ETL becomes increasingly difficult to implement as data becomes more complex.

ELQT

ELQT stands for ‘Extract, Load, Query, Transform.’ As data demands become larger and more pressing, high-velocity data streaming becomes necessary. Data streaming could come from services such as Kafka, Pulsar, Kinesis or others.

This drives the data into a data lake where it’s never seen again. Or you could employ data visualization platforms like Apache Spark which allows developers to query and transform data, making data visualization and analysis more possible.

Once APIs hit the marketplace, issues begin to emerge.

The Evolving API Platform

Higginbotham recommends starting with what you’re trying to achieve and then focusing on the API. He breaks down the easiest way to assess APIs into two components: capabilities and operations.

The easiest way to assess API capabilities is known as Application-Level Pragmatic Semantics (ALPS).

What Is ALPS? An Overview

ALPS is a protocol-agnostic format for representing an API’s capabilities and the core value fields involved in using that capability. It becomes an interface definition for APIs.

This allows developers a framework for assessing API capabilities and then defining those capabilities in a machine-readable format, allowing the API to interact with other environments, such as OpenAPI, or servers, using HTTPs.

The Journey Towards An Enterprise API Platform

The enterprise API journey continues to evolve. Initially, an enterprise may think of things only as a series of in-house APIs to help automate internal functions. Things get more complex as more developers start using the APIs. They get even more complex when a layer of data streams and analysis are integrated. Higginbotham posits we must think beyond the basic REST interface to handle all of these additional layers.

Functions As A Solution (FaaS)

One way to cut through complex layers is through adopting Functions-as-a-Solution (FaaS). FaaS offers the ability for APIs to bridge out to other systems, allowing developers to quickly create new products and push them to market.

The possibilities are nearly endless when combined with the serverless aspects of Platforms as a Service (PaaS). You only have to write some deployment code, and you can quickly have a new product running 24/7.

The Future Of APIs

“We’re moving into a new world where users no longer turn to applications to get things done,” states Higginbotham. “Rather than the users turning to applications, the applications are coming to the users.”

Messaging and collaboration platforms are especially indicative of this progression. In these environments, instead of sending an email telling someone to open a particular application, certain events may trigger a particular process.

Higginbotham is full of sage advice on the current state of API design. He leaves us with some further ideas:

• Scalability: Today’s API processes may not be scalable. Rather than constantly building and deploying APIs, Higginbotham advocates for a return to Client-Server formats like the old days of Visual Basic.
• On marketplaces: Our marketplaces move even more quickly than they did in the ’90s when Client-Server solutions reigned supreme.
• Low code is back in style: Low-Code/NoCode solutions are going to be even more important than they were in the ’90s. Things like Node-Red allow JavaScript to run IoT solutions and to stitch APIs together. Solutions such as Zapier or ifttt.com make automation possible without writing a single line of code.
• Data analytics is important to the data-driven economy: Programs like Apache Airflow allow developers to run data analytics inside of a data pipeline and design directed acrylic graphs (DAGs) to process data both in both parallel and serial.
• Frameworks for integration: Finally, there are languages like Ballerina to write microservices allowing APIs to communicate and integrate. Integrating APIs is going to be increasingly important in the future of APIs, going forward.