API management has evolved dramatically over the last 20 years. You could go back further in the history of computing and end up in the late 1960s when the term “application program interface” first appeared in literature. But let’s just look at the more recent past.
A Brief History of API Management
The World Wide Web’s success (does anyone still say WWW?) was the initial spark. Invented in 1989, it really took off with the first user-friendly browsers like Netscape, introduced in 1994. That was the first time when everyone could see and experience the potential of a worldwide computer network with standardized interfaces.
The triumph of the human Web in the mid-1990s was followed by the success of the machine Web. XML (February 1998), XML-RPC (June 1998), and SOAP (May 2000) followed in short succession. Salesforce, as one of the first visionary SaaS companies, started using the term API for network-based interfaces in February 2000, in a rather creative repurposing of a term that previously focused on local interfaces. eBay, another early API user, published its first APIs in November 2000. Soon, APIs became the talk of the town.
The First Hype
SOAP was the first major trend in the API space. But it initially suffered because of the underlying Extensible Markup Language (XML) technology which was often seen as cumbersome. XML was conceived more for documents than for data. The approach to working with data in the form of trees with elements and attributes wasn’t obvious to many, which made XML seem bulky.
Additionally, the SOAP standard wasn’t without its technical issues from the start. SOAP was pushed in a very short time by a vendor-driven standardization furor (the infamous WS-* extensions) into an unpleasant combination of interoperability problems and the question of cost/benefit.
When it became clear with the invention of JSON (popularized in 2002) and the idea of RESTful Web services that APIs could be simpler, their success continued to pick up steam. Starting in the mid-2000s, newer APIs relied on HTTP/JSON instead of SOAP/XML. That made all the difference for what is now called Developer Experience (DX). Suddenly, you could produce and consume APIs without complex tools and libraries. This opened the eyes of many SOAP critics and skeptics to the potential of APIs.
Almost Like a Web Server
With JSON over HTTP, it was much easier to create APIs. But what about security? There was a fast-growing landscape of available APIs but since they often offered services relevant from a business perspective, they needed to be secured. With the idea of a web server as a generic component, there had already been a good architectural template for this problem (for example with Apache, launched in 1995).
Thus, the API Gateway was born. It was the first successful component in the API environment and is still widely used today. Take a reverse proxy (in Web Lingo), teach it API formats (JSON and XML) and how to deal with them, add features for authentication and authorization, and round it all off with configurable controls for access. Now you have a component that’s useful to many and easy to deploy. That isn’t a bad recipe for a product category with potential.
A date that we didn’t mention in our short history of API management is 2007. This date is another spark for the web and the Internet. It was the year Apple introduced the iPhone. Very soon, many people had an “always connected Internet computer” in their pocket, and entirely new business ideas (and user demands) began to emerge.
Initially, it was fairly specialized providers and niches where APIs were able to establish themselves. The API economy and the dynamics in the API sector picked up considerable speed from 2010 onwards. More organizations realized that they had to deal with the consequences of comprehensive global digitization whether they liked it or not, either by leading with innovation themselves or as a defensive measure to hold their own against more innovative competitors.
From this perspective, as of 2010, APIs increasingly emancipated themselves from their purely technical aspect and became understood and managed in companies as strategic building blocks at the business level. Although this still isn’t entirely practiced everywhere, all indicators suggest that companies achieve a strategic advantage when they understand and use APIs as business building blocks.
But in the end, APIs aren’t magic and they can’t change a business on their own. From this perspective, the “API determinism” that’s sometimes practiced is more harmful than beneficial. This idea assumes that you only have to have APIs and everything will change for the better. Unfortunately, it’s not quite that simple. In the end, both digital business strategy and the “composable business” have to be implemented with hard work. But when that happens, APIs are the foundational tool with which all the new possibilities are realized.
Shiny New Toys!
As APIs become more widespread, the breadth of application fields and the importance of specific scenarios also grows. In 2015, Facebook began to propagate GraphQL. It’s specifically designed to make communication between mobile apps and their application servers more efficient, especially in the case of complex and flexible data models.
Over time, GraphQL became widely adopted. Still, its focus is largely on tightly coupled, private APIs and the security aspects remain a challenge. But like all technical issues, these can be solved. So far, GraphQL’s popularity is still on the upswing.
Something similar is currently happening in the area of event-based APIs. A new approach is competing with the old models. Like GraphQL, event-based APIs have their strengths. There are other scenarios where their use is less clear-cut. Event-based APIs are following GraphQL’s popularity trend right now and both are being hailed as “more modern” and “better” than HTTP-based REST. True or not, it certainly is proof that the hype cycle in the technology sector is inevitable.
Which Maslow’s Hammer Works Best?
It’s a familiar pattern in IT. New technologies compete with the old ones. While some see this as an interesting expansion of the solution space, others find the new technologies so compelling that they promote them as the only solution. Without taking a definitive stance on this thorny issue, it’s at least interesting to consider that the entire API sector is growing so quickly that a bit of variety might not be such a bad thing.
We’re also seeing more discussions in the API community move away from absolute positions when it comes to technologies. Instead, now it’s clear that API management in the larger sense (not just the technical management of individual endpoints) is more about processes, practices, and platforms. Technology must work well and play its role, but it doesn’t solve the underlying issues per se.
More and more, the issue of how an organization can translate its API strategy into an API program is coming to the center stage. How do you balance the act of decentralizing for greater speed and flexibility, while also harvesting the advantages of centralization in terms of economies of scale and visibility? These new, less technically fixed discussions are a clear indication of APIs shifting to business building blocks. A technology topic is slowly coming of age.
COVID-19 as Food for Thought
From 2020 onwards, the COVID-19 pandemic can be seen as another milestone. Depending on the organization it revealed areas where “business as usual” was relied on too much. Organizations were overwhelmed by the need to suddenly operate in significantly different ways. While digital transformation demanded change over a period of years, with COVID-19 it was suddenly a matter of months or even just weeks.
Practical action for organizations often meant moving to more and better online services because traditional channels were hampered by COVID-19. For organizations with an established omnichannel strategy, always underpinned by APIs, this was much easier than for those who had given little thought to how their markets and channels may change.
Apart from concrete measures, COVID-19 made it clear to everyone how unexpectedly and quickly the world can change. For many, it’s food for thought about how to be better prepared for the next surprise. No one can say exactly what that surprise will be. However, an obvious prediction is that it will demand organizations to be flexible and adaptable. In the end, that simply means facing the challenge of digital transformation, which is always underpinned by APIs.
API Management is Growing Up
If we combine the increasing importance of APIs and growing technological diversity, we see that it will become increasingly difficult to find universally applicable answers in the API field. But there are also increasingly better opportunities to find a suitable mix of technologies and tools for specific objectives.
What does this mean in practical terms? As previously mentioned, we’re already seeing that the focus is shifting more from technology determinism (“choose technology X, and all your problems will be solved”) to focus on processes, practices, and platforms. The increasingly complex API world is focusing more on how to deploy, combine, support, and replace technologies. Topics like “API governance” and “setting up and running API programs” are gaining importance because, without them, we cannot achieve our end goal of an API program, which is to deliver business value through the use of APIs.
From Technology to Value Creation
The exclusive perspective on APIs as technical interfaces is increasingly being replaced by a more holistic view. APIs are always a means to an end, and this end must be kept in mind in order to manage API investments as effectively as possible. Technical concerns will always have their place, but they are supplemented with business-oriented considerations.
APIs are, at the technical level, equivalent to the general effort to make organizations more flexible and easier to change. Because of that, it’s important to check if your APIs are the right interfaces to transition monolithic organizations into ones with better modularity. As with any modularization, the devil is not so much in the details of technically implementing interfaces, but in identifying a useful set of modules.
This isn’t to minimize the importance of solid craftsmanship. For example, APIs without a good concept of how to make non-breaking changes or manage non-breaking versus breaking changes will almost never be a good implementation of the API idea. But of course, this is true only within limits. For example, if you control both the clients and servers, like with GraphQL as a backend for UI frontends, then you’re operating in a different space than in scenarios where you might serve a large number of consumers that you have no control over.
However, these types of design constraints cannot be answered without a clear definition of your APIs’ business goals. It’s a good idea to clearly define the business justification for each individual API. How does it serve the end goal of creating business value? Even if the answer is indirect, there always should be a clear answer or you should ask yourself whether the cost of managing the API is a good investment.
API Management Trends in 2024
If we are in fact headed towards a future where APIs move from technical to business interfaces, what trends can we predict?
- Greater focus on “why” instead of “how”: We want to create good API products and we want to make sure that they are useful and usable. The view of the API lifecycle management will become more comprehensive and there will be more focus on implementing the right APIs, without being guided primarily by technical considerations.
- New roles in the API segment: There will be new roles in the API sector. The API Product Manager role is becoming more important. This can focus on a single API product or be a support role for advising API teams on what to consider during the lifecycle of an API product. Other roles will emerge. For example, we’re already occasionally seeing the role of Chief API Officer (CAO) which clearly indicates the topic’s strategic role.
- Better business-oriented tools: With an increased focus on APIs’ business benefits they need to become more understandable for non-technical users. Why does an API exist? What business benefits does it generate? How does it fit into business-oriented enterprise views, like a Business Capability Map (BCM)? Today’s API tools are almost exclusively aimed at technical users but this focus will expand. This means opportunities for API vendors that are the first to make the change, bringing their products closer to business users.
- Better management of consumed APIs: Right now, the focus of nearly all API management tools is on the production of APIs. But what about consumed APIs, especially those outside your organization (you can think of these as your “digital supply chain”)? There are dependencies and risks that haven’t necessarily been seen as part of API management yet. These dependencies will continue to grow since there are more consumable services. Managing these dependencies better will become more of a focus.
- Unbundling API tools: Usage of APIs will continue to increase and therefore, API landscapes will also continue to grow and become more complex. It will be more important and easier to combine different API tools to meet your needs. Ironically, this development will lead API tools to rely more on APIs themselves so that they can be combined more easily and openly.
- Yes, AI will play a role in API management. But since everybody is talking about AI these days anyway, we don’t have to repeat it here. One of the goals of this article is to show the complexity of the API management space and for some of the issues discussed here, AI may offer new ways of approaching them.
These developments provide a brief overview of trends we can expect in the API field. Of course, there will always be new technologies. But, like in other fields, these will prevail in specialized areas instead of completely displacing existing ones.
What can we learn from this development? Roughly speaking, it reflects what’s also happening in areas beyond APIs. Business and technology are growing closer together. Business without technology is becoming less conceivable. Technology is becoming more important for businesses and because of this, the two must move closer together.
Therefore, you can conclude that there’s a need for learning on both sides. There are still (too) deep rifts, especially in non-technical organizations. The friction and delays can be enormous. What are good ways to promote mutual understanding?
- For engineers: Designing and managing APIs as products. The step from integration (APIs for connecting two components in a project) to “real” reusable APIs is difficult for some developers, or is simply not part of their vision. Understanding APIs as reusable digital building blocks maximizes their benefit for the organization. This needs to be established and cultivated as one of the strategic goals of APIs. Experience shows that internal initiatives to explain this “API product culture” can help with establishing that API mindset.
- For non-technical people: Deeper engagement with possibilities and variants of digital business models. Digitization opens up many possibilities beyond what was previously possible. Too often non-technical organizations say, “We are not Google”. It’s true, of course. However, it ignores the ways that their own products and processes could be improved and supplemented (without completely replacing their core business). This is where API business model workshops often come in handy, helping with basic technical knowledge and understanding how it can be applied at the business level.
With that, we’ve looked at the prospects for API management and what changes they should entail. APIs are going to become more numerous and important, so the sooner we start looking at what they can do, the better. APIs are and always will be technical, but their importance and visibility at the business level will increase. This is something that all stakeholders will have to deal with.
Read more articles:
5 API Styles Any Decision Maker Should Know
David Roldán Martínez: API Economy
I’m an experienced and internationally known professional in the space of digital transformation and API management. I started out as a technologist with degrees in computer science from TU Berlin and ETH Zurich. I worked as a Professor at UC Berkeley but ultimately joined the software industry. I have worked in a variety of companies, always focusing on improving the way in which information systems can help an organization and its customers or clients. I’m the author of many articles and papers, various books, and multiple standards, and regularly speak at conferences around the globe. My “Getting APIs to Work” channel on YouTube is a place where developers, IT professionals, product managers, and digital leaders get regular updates about technologies, tools, events, standards, and the global API community.
