The Problem with Ubiquitous APIs

APIs have increasingly changed how businesses function, both internally and externally. Organizations are more distributed—with their employees and their software. There are more devices and other systems that require API-driven solutions, which has led to an expansion of API programs in the enterprise. While the flexibility of APIs enabled this rapid growth, it caused a new set of problems.

With ubiquitous APIs, much more data and functionality is shared across an organization. Simultaneously, most companies have even less visibility into how their software interacts and where there are opportunities for improvement. The same things that make APIs successful are also bloating enterprise development.

Modern APIs Grew Organically

Before APIs, as we know them today, there were other approaches defined for exchanging data. With them, internal sharing was the primary motivator. When popular web companies opened public APIs twenty years ago, it started a trend that changed the software landscape permanently.

In the late 1990s, the Internet was still in its commercial infancy. Where databases were once the hub of data-connected software, new possibilities emerged with remote procedure calls. Service-oriented architecture (SOA) became the means for designing connected software around these application components.

Amazon famously mandated that all teams expose their functionality through “service interfaces.” That was in 2002, the same year that Amazon published its first public API. Salesforce and eBay had done the same a couple of years earlier. These three giants of the Internet provided the first examples of modern APIs.

The SOA approach was intentionally agnostic to how it was implemented. That meant an engineer at two different companies might make interfaces that look very different. Public APIs, by comparison, provided examples that anyone could emulate internally. Indeed, these early entrants used the Simple Object Access Protocol SOAP APIs, a messaging standard defined by the W3C.

The move from SOAP to REST occurred over the next 10 years. Developers embraced a more flexible approach that also used a convention that encouraged familiar interfaces. Now GraphQL has emerged as another alternative interface, led by Facebook. However, the pattern with these modern APIs remains: public examples encourage internal technology choices. An engineer can jump into a new company and build upon its foundation of API knowledge.

Just as engineers can easily consume APIs, they can also quickly create and expose them. Enterprises typically have hundreds or thousands of APIs. In most organizations, it’s easier to build a new interface than to understand what already exists. This growth is a natural offshoot of the industry’s path to modern APIs. Many organizations take action to direct how their APIs expand. They can’t put a stop to the rapid expansion, nor would they want to stop its growth—their businesses rely on these APIs to function.

Almost All Software Requires APIs

Along with API growth in the enterprise comes a reliance upon those interfaces. In concert, we’ve moved from centralized computing to a distributed model. There are many different devices and systems that need to access an organization’s APIs. Not to mention, partnering with external collaborators also depends upon APIs. The concept of any “non-API software” is dwindling.

Long ago, you would buy your software in a box and install it on your machine. Even in the early days of the Internet, the box was replaced by a download. Once installed, your connection might only be used to update the software. This is obviously an antiquated definition of software. Even desktop applications now frequently make use of real-time interactivity through APIs.

Similarly, phone and tablet apps are driven with APIs. Any IoT device must include an interface to send and receive updates. Many websites and every software-as-a-service need APIs to connect the front-end code to the server-side logic. Anything an engineer builds today is likely to consume or provide an API—or both.

Because APIs are ubiquitous, it is difficult or impossible for a company to quantify what they have available. Counting APIs is only the first step toward deeper analysis. Expansion of APIs may be natural, but it’s hardly efficient.

Building software is expensive and most organizations have no idea how much time, money, and opportunity they’re wasting.

No API Governance is Strong Enough

The growth of modern API programs was made possible by public examples that were easy for engineers to emulate. The expanding number of interfaces was further needed to support just about every software project started in the last 10 years. Yet, the problem with ubiquitous APIs is we can’t easily grasp everything that our engineering teams create. But organizations certainly try.

When a company or business unit looks to apply API governance, there are a few issues on their mind. They know their API program is full of:

• Duplication
• Inconsistency
• Antiquation

As a solution, they look to impose requirements for how APIs are built. These guidelines can be incredibly helpful, especially for new teams. However, these rules typically only apply to new APIs. There’s little insight into whether existing interfaces are compliant. At the same time, governance can be seen to create a bottleneck, due to a manual review process.

The answer can’t be no governance, because the expanding APIs got us to a place where we know there are problems to solve. However, a centralized solution won’t solve a decentralized problem. No iron fist of API governance will hold back the growth of enterprise API programs.

At Stoplight, we focus on providing solutions to scale API design, especially in terms of governance, but we also include the most powerful, easy-to-use design-time environment available. We don’t claim to have all the answers, but we want to help navigate your many APIs better—and the guidelines and assets that are within them.

Check out how Stoplight helps governance and visibility across enterprise API programs.