If you’re a developer of any type of modern application, then you’re likely more than just familiar with APIs—you’re probably a power user. Today’s applications, built for consumers and producers of endless content, are interconnected. And APIs are the glue that connects those applications, serving as the primary vehicle for communication between separate services.
As the usage, development, and productization of APIs have blown up in recent years, we’re looking at a new trend that’s on the horizon: API democratization and API management. In this post, we’ll look at where APIs have been and where they’re going, specifically considering the role of API democratization and management in the future of APIs.
Where APIs Have Been
Let’s start with a look at the past, examining how the need for APIs first came about and why APIs have historically been solely the domain of developers.
The API as a contract
An API represents a contract between two parties. Those two parties are the provider (sometimes called the server or publisher) and the consumer (sometimes called the client) of a service. An API is an agreed-upon interface (the I in API) that the two parties will use to communicate. This interface includes stipulations about how an API will be reached (a URL), message formats, actions that can be performed, and security requirements for communicating.
The Swagger Petstore is a classic example of an API definition that adheres to the OpenAPI Specification. Every API endpoint has a clearly defined URL and request method, along with requirements and expectations for security and the format of requests and responses.
In today’s world, APIs are generally expected to be accessible over styles or protocols like SOAP or REST. Today’s usage of the term API primarily refers to their usage in web services. Several decades ago, however, different components within an application (like a local, desktop application) had APIs to facilitate communication with one another. At the time, APIs were simply code libraries used to abstract different tiers of an application.
As Web 2.0 matured and cloud computing became the norm, the use of APIs expanded, standardizing how different black-box applications would communicate with one another. By using APIs to specify how different services would communicate, the implementation details of those services—including programming languages or frameworks used—became immaterial. This meant services of all different kinds could work together, as long as they all had well-defined APIs. APIs are what allowed applications to scale across multiple servers and data centers.
More recently, applications are being designed and developed specifically around available APIs. Organizations are on the lookout for innovative APIs that are available—perhaps open and free, or for a subscription fee—and they are building fully-featured applications (and entire businesses) that leverage those APIs. This is opposite to the direction of the past, in which APIs were built to suit an application’s needs.
Developers as the sole contributors to API design
From the start, APIs have been designed and built by developers based on stakeholder needs. The stakeholders would provide a set of requirements, and the development team would decide what the contract should be and build it. Whether the API was built by internal development teams or in collaboration with external developers, the task of API design was the developer’s responsibility. At the time, this made sense because the developers were the ones who would build the API, and quite frankly, they were the only ones with the insight as to what goes into API development.
In short, stakeholders would drop off a requirements document and then walk away. After that, every remaining aspect of building the API—from design to development to deployment—was solely the domain of developers.
Where APIs Are Going
As the business of API development shifts, entire applications—and in some cases, entire businesses—are being built around suites of APIs. This shift brings with it the need for two new disciplines: API democratization and API management.
API Democratization
We touched on how, in the past, developers alone informed the entire lifecycle of an API, and this included API design. API democratization involves opening up the API lifecycle—specifically, the design stage—for others in the organization to speak into.
If the sole product of a business is a set of APIs exposing the secret sauce of that enterprise, then what goes into and comes out of those APIs needs buy-in from more than just the developers who code them. Everyone, from C-Suite stakeholders to product managers, needs to be on board with the design of an API. This is no longer the domain of just the highly technical.
Strategic thinking is required to make sure a company’s APIs (which is synonymous with “products”) don’t overlap and create redundant functionality. A company must ensure that every one of its APIs meets the following criteria:
- Meets the saleable needs of the enterprise. Companies shouldn’t sell products that customers aren’t willing to pay for. APIs, similarly, must bring tangible value to the company, positively impacting the bottom line.
- Addresses the competitive environment it serves. Just like with products, API-building organizations must be familiar with their competition. What value propositions does an API deliver? What segment of customers does an API reach, and how does it do so more effectively than its competitors?
- Is designed with futureproofing in mind. New technologies emerge rapidly. Regulations for data privacy and security are a moving target. Consumer trends shift from one quarter to the next. Is the API designed to withstand and adapt to these changes?
No longer can business analysts simply create specifications and hand them off to development teams. Instead, a much more prescriptive process must take place, ensuring that the APIs being developed actually meet the demands at every level of an enterprise, whether they be for internal or external use.
Successfully delivering APIs and API-based applications now requires everyone to have a seat at the table. What does this mean for companies? It means the need to adopt tools and platforms that can facilitate this democratized approach. These platforms would provide low-code or no-code API design tools that empower stakeholders to function as co-pilots alongside developers.
Siloed development is a practice of the past; API democratization is taking its place.
API Management
This brings us to the next area where API development is changing: strategies for API management. API management simplifies the task of keeping track of all of the APIs published by a company—along with their versions, environments, and usage.
Businesses today build applications that may depend on hundreds or thousands of APIs. Those APIs are deployed to internal data centers and multiple cloud providers, with some available to the public and others with only privileged or private, internal access. Some APIs may even be customized for specific consumers. In addition, each API may have multiple supported versions.
With this level of scale and variation, it is no longer possible to manage APIs with source control and spreadsheets alone.
Enterprises embracing the trend of “API as a business” need to rely on tools that can handle the scale and scope of modern API development. API management tools can help an organization keep track of the following:
- Versions
- Deployment environments
- Deployment locations
- Customers (API consumers)
- Usage metrics
- Interoperability
- Relationships with other APIs
- Dependencies
API Management tooling can also deliver higher levels of reliability and security through API Gateways and the implementation, configuration, and management of policies such as, but not limited to:
- Rate limiting
- Traffic shaping
- Data masking
- Various types of authentication
- ... and more.
Although management tools come in many flavors, those with the biggest impact are visual tools that come with rich UIs analytics, etc. while still offering CLI-friendly capabilities for the DevOps teams out there. This way, teams can work within the bounds of their skillsets and preferred approaches while still having a clear understanding and control of workflows, API consumption, and activity across the API lifecycle.
When we consider the scope and scale of API needs in today’s enterprises, manual and ad hoc management is, at best, high-risk and error-prone. However, effective API management tools could simplify and streamline what was once a daunting and impossible task.
A New Generation of Tools
Among the new generation of tools addressing the evolving business of APIs is Gravitee. The Gravitee platform includes tools that will help any organization on its journey toward effective API democratization and management. Its API Designer is a collaborative tool that provides a flow-chart approach to API design. Business stakeholders, product managers, and developers can work together to translate requirements specifications into a high-quality API definition and data model. This is especially useful for teams that have chosen to take a design-first approach to API development.
Beyond design, the API Gateway and Management console provides features that include:
- Low-code/no-code policy configuration with a drag n’ drop policy studio
- The ability to implement API plans and contracts to manage and govern consumption
- API documentation management
- The ability to push APIs and their documentation to a consumer-facing Developer Portal
- The flexibility to mediate protocols and connect synchronous APIs (i.e. REST APIs) to asynchronous systems and APIs (i.e. a centralized Kafka backend)
Gravitee Cockpit is a cloud-based tool for the centralized management of an enterprise’s entire deployment. With Cockpit, an organization can view, manage, and access their Gravitee instances and environments, and they can promote APIs across these various environments.
Conclusion
Over the decades, application development has evolved from self-contained, monolith applications to distributed, globally accessible, cloud-hosted behemoths that can be the driving force of enterprises. Surviving and competing in today’s API development landscape requires an organizational shift. That shift involves the adoption of tools that facilitate the democratization of APIs and simplify their management. As organizations begin using these tools, this only enhances the efficiency of their processes and reduces time to delivery.