It’s obvious to anyone who reads tech news that the IT industry is undergoing a Cambrian explosion in the business applications space, with ever more specialized SaaS and micro-SaaS offerings being funded and coming online as we speak. This trend is being fueled not only by venture funding and the recent AI breakthroughs, but also by the mass layoffs that are happening in the software industry.

I will argue here that the IT sector is not ready for this new ultra-fragmented software landscape. I see integration as the Achilles’ heel of this new world, with the shortcomings of the 24-year-old REST protocol and others becoming ever more apparent, such as their lack of composability and interactivity.

Given these integration limitations, large software suite vendors still have a competitive advantage, as they can offer tightly integrated applications through shared internal infrastructure. The onus is on the integration technology vendors to even the playing field between application suites and best-of-breed applications and unlock collective innovation. The good news is this is possible.

The Changing Software Industry Is an Opportunity for the API Industry

Nowadays, businesses are more reliant on SaaS than ever before, and employees are having to juggle between ever greater numbers of applications. A Better Cloud survey found that organizations were using an average of 110 SaaS apps in 2021, a 38% increase from the previous year.

And how are the employees faring in this environment? A Gartner survey revealed that the average number of applications a knowledge worker was using in 2023 was 11, compared to six applications in 2019. Forty percent of digital workers use more than the average number of applications, and 5% of workers use 26 or more applications at work.

Compared to big application suite vendors, the great advantage of using specialized SaaS applications is that businesses can pick best-of-breed solutions in every software category. However, one of the downsides of this approach is that having an integrated IT system now becomes a thorny matter. Integration is a valuable business outcome because, on the one hand, businesses like having a consolidated view of their IT, and on the other hand, employees prefer not having to context-switch between multiple applications for tackling any given task. So it’s not only about integrating IT but also about integrating UX.

What Is Missing From the Current Web API Landscape?

To see why integration is such a big unsolved issue with SaaS, it helps to examine the current state of affairs. Firstly, the fact that the vast majority of SaaS applications provide a REST API is a sure sign that the SaaS vendors themselves view integrations as mission-critical. Secondly, the fact that most SaaS integrations still rest (!) on a 24-year-old API protocol speaks volumes about the lack of innovation at this base layer of all networked software.

To illustrate that last point, here is my take on a well-known XKCD web comic.

The big feature missing from REST and all other API protocols is composability. This means that an API cannot call another API behind the scenes if the end-user must be authenticated.

As a consequence, REST and similar protocols only allow API-to-API calls if user authentication is not necessary. For example, REST remains a viable server-to-server protocol if APIs only need to authenticate the calling server and not any particular end-user.

And there is another problem with API-to-API calls with these protocols. Indeed, when APIs are allowed to call other APIs behind the scenes, then in some cases, the API developers may no longer guarantee a timely API response because they no longer have an overview of the API dependencies, and this can even lead to network timeouts and aborted API calls.

So, why is composability such an essential part of a healthy API ecosystem? To answer this question, it’s helpful to make a clear distinction between APIs involved in user-facing processes and applications and APIs called from cloud backends and largely disconnected from user-facing processes. While network timeout risks can be kept in check for the latter, user authentication, and thus composability, is essential for the former.

Now let’s briefly examine the types of architectures that the IT industry has imagined in the absence of composable APIs. Firstly, micro-frontends. These are not APIs but parts of web pages, and they cannot be nested beyond a couple of levels. Also, they are generally suitable for intra-organizational use cases but not for inter-organizational use cases.

Secondly, MACH architecture. This architecture uses non-composable APIs such as REST for user-facing applications. With this architecture, the application frontend is both a performance bottleneck (a frontend must implement the UI layer for all APIs, and all API-to-API integrations must go through the frontend) and a security risk (APIs must trust a third-party frontend not to misuse their users’ credentials).

The Composable Web API Era

Now, let’s imagine what a composable API protocol might look like. Clearly, having direct access to the end user is the most secure way of authenticating the end user without having to trust any third party, so let’s add that to our list of requirements.

Also, it is immediately apparent that once an API is interactive, that interaction capability can be used for many interactive processes, not only for authentication. Interactive APIs effectively represent a new type of API that operates at the business logic level and, in addition, brings its own user interface.

We could then have a general-purpose platform for distributed applications where the end-user is redirected from API to API as required by the task. The user experience would remain very similar to using a single-site application. That, plus not having to switch between applications would lessen the end-user’s cognitive load compared to today.

This API platform can be imagined as an upgrade to the web platform, and one immediately notices that distributed applications are a fundamentally new capability that neither the mainstream web platform nor the native desktop and mobile platforms are able to offer.

What kind of capabilities can such a platform unlock? Distributed applications can be built on top of internal applications, partner applications, and SaaS to build cohesive IT systems and employee UXes. Any mix of internal, partner, and SaaS applications can be integrated with each other. The user interface layer of microservices architectures can be spread on several websites, thus removing productivity bottlenecks for multiple teams working in parallel.

Lastly, implementing integrations would be much easier than with REST and similar APIs because much of the user interface and all of the user authentication would be implemented by the API itself. Also, there wouldn’t be any need for an API key because API calls would be similar to regular web redirections.

Conclusion

A new era of SaaS and micro-SaaS proliferation is upon us. This is the right direction for the IT industry to head towards at this juncture, despite the new challenges that are becoming apparent.