What are API 1.0 and 2.0 anyway?

When you browse our website, you will find a lot of references to API 3.0 or the third wave of API Management (APIM). But if we arrived at the third wave of API Management, then what are API 1.0 and 2.0?

API 1.0 – The early days

The meaning of what an API is and how it works shifted when Internet technologies became widely distributed. Interactive experiences pushed aside the formerly information-centric websites. Before that APIs usually referred to a library, which can be embedded by application developers into their desktop applications. With the fundamental shift to interactive web APIs became a synonym for web services. Companies started to think about how to make their data and services available in a way that is easy to consume by web and mobile developers.

Service-oriented architectures were all the rage with companies running large SOAP-based enterprise service buses. The obvious idea was to bring these services to the outside and make them available. To do this securely a new breed of edge gateway was created: The API gateway was born. Heavily based on enterprise standards like WS* some of these systems are still around. You can still trace back the modern API Management language to these origins. Policies and assertions have their roots in the WS* specifications.

Besides the web service specifications themselves, there were no common elements. Open Computing was still years away. All these early systems were closed-source, heavy-weight enterprise products. As most of the backend systems themselves didn’t supply web service APIs, this generation usually comes with a lot of features to turn data into APIs.

They are not a thing of the past, though. A lot of enterprise APIs still rely on the feature-richness, robustness, and support of older standards like SOAP.

API 2.0 – Do it again

Multiple disruptive changes in the IT industry lead to the second wave of API Management, or API 2.0 for short. Enterprise-grade technology comes with a quite hefty price tag. Way too much for start-ups. They also come with a lot of processes and a lot of standardization and tooling. Most of these tools were not adopted by the internet community. In the search for simpler, web-native alternatives, the internet widely adopted REST-based APIs. And the API Management solutions followed along.

The second disruptive change was harder to adopt. Transforming a heavy-weight, less scalable platform into a cloud-native, hyper-scalable one is no small feat. New players quickly covered this niche. These newer solutions are based on different ideas and values and are what we consider to be the second wave of API Management. While some of them adopted an open-source first strategy, they still do not feature any interoperability with other solutions. The goal was to replace the existing solutions, not to work in tandem with them. So while the technology changed dramatically and the adoption of open source drastically reduced the entry barrier, the business models didn’t change so much.

Despite processing as many requests per second as possible, another capability became increasingly important: The actual management part of API Management. The platforms grew and offered developer portals, API design, and testing tools, and everything else needed to build a comprehensive full-life-cycle experience. While these platforms provide great value, their inherent problem is, that they do not work together with other API Management solutions very well. Leaving a lot of opportunity at the table.

Where do we go from here?

The common mistake of API 1.0 and 2.0 solutions? They treat API Management as a tactical tool. However, APIs and a good API-first strategy are so important in the modern marketplace, that APIs need to be looked at as a strategic asset. The management has to be split from the gateway and API security has to be elevated to the next level. As many of our customer projects showed us, there are a lot of reasons you might want to run more than one API platform. Being it a hybrid or multi-cloud strategy, mergers or acquisitions in the past, or just the urge to use the right tool for the job.

This is the reason we decided to lead the pack in the move to API 3.0. This shift gives organizations more options, better governance, and less risk without sacrificing any capabilities built during recent years.