The World Wide Web’s success (does anyone actually 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 Network is the Computer.

The triumph of the Human Web from the mid-1990s was followed by the success of the Machine Web. XML (February 1998), XML-RPC (June 1998), and SOAP (May 2000) follow in short intervals. Salesforce, as one of the first visionary SaaS companies, started using the term API for network-based interfaces in February 2000, in a slightly creative repurposing of the term that previously focused more on local interfaces. eBay, another early API user, opened its first APIs in November 2000. Soon, APIs became the talk of the town and really took off around the year 2000.

The first hype

SOAP was the first major hype in the API space. But it initially suffered because of the Extensible Markup Language (XML) base technology, which was often seen as cumbersome. XML was available more by historical coincidence and by virtue of being the first platform-independent serialization format on the Web. However, it was originally conceived more for documents than for data. The approach to work 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 doubts 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 justified question of effort/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 in what is now called the 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 on top of HTTP, now it was much easier to publish 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 standardized component, there had already been a good architectural template for this problem (at the latest 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. 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.

It starts with the API economy

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 internet. It was the year Apple introduced the iPhone. In a short time, 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 have to deal with the consequences of comprehensive global digitization whether they liked it or not, either by leading the 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 accepted and practiced everywhere today, all indicators suggest that companies achieve a strategic advantage when they understand and use APIs as business building blocks.

Of course, 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 useful. This implicitly 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 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. Specifically, it’s used to make communication between mobile apps and their specialized application servers more efficient, especially with regard to the complex, flexible data model that forms the app’s basis.

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 is still on the upswing.

Something comparable, but somewhat delayed, 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 appropriate. 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. 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 more 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 and practices. Technology must fit and play its role, but it doesn’t solve the demanding 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 manage the balance act of decentralizing to a certain extent for greater speed and flexibility, while also retaining 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 cited as another milestone. Depending on the organization, it bluntly revealed areas where “business as usual” was relied on too much. Organizations were overwhelmed by the need to suddenly act in a significantly different way. While digital transformation demanded changes 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 very 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. But an obvious prediction is that it will demand organizations to be flexible and adaptable. In the end, that simply means facing the ideas of digital transformation, which is always underpinned by APIs as a foundation.

Manage complex distributed systems

Explore the API Management Track

Learn more

The field is getting wider

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 focusing on processes and practices. 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 initiative.

From technology to value creation

In summary, the developments described so far are as follows. 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.

If you accept the premise that APIs are, at the technical level, equivalent to the general effort to make organizations more flexible and easier to change, then they need to be looked at from a technical perspective and seen if they’re 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 it, but more in finding the right sections.

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. 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 (mostly mobile) 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 our APIs’ business goals. Technology-focused snapshots can sometimes be correct, but then it’s more because of luck than well-deserved success. It’s better to take a step back first and ask which tasks the API should take on in which context.

API trends in the near future

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”: Technically sound APIs will still be in demand, which APIs and with which goals you implement will be more important. 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 also 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 big 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? 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 them 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 best. Ironically, this development will lead to API tools to rely more on APIs themselves so they can be combined more easily and flexibly.

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 subareas instead of completely displacing existing ones.

Learning requirements on both sides

So what lessons 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, it must become more involved.

Therefore, you can conclude that there’s a need for learning on both sides. There are still (too) deep rifts, especially in non-inherently 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 many developers, or is simply not part of their target vision. Understanding APIs as reusable digital building blocks maximizes their benefit for the organzation. But it needs to be established and cultivated as one of the development process goals. Experience shows that internal initiatives to explain this “API product culture” can help on how this can exist in practice.
• 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-inherently technical organizations say, “We are not Google”. It’s true, of course. But 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 (we call these “Digital Re-Programming for Leaders’) often come in handy, helping gain basic technical knowledge and understand 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 continue to have to deal with, and increasingly so.