API history from REST to AI
Today’s SaaS solutions are built around the API economy, an ecosystem of business models and practices rooted in APIs from organizations across various verticals. Thanks to the API economy, it’s never been easier to integrate your app with third-party apps.
If you need to add functionality to your app, there is an app for that. Today, you can enable your users – both developers and non-technical – to choose how they want to integrate your product with other apps they might be using.
It’s easy to take these integration capabilities for granted. However, to truly appreciate how we got here and where integrations are headed – hint: it involves AI – it’s essential to understand how and why things evolved the way they did.
History of REST API
Let's rewind to the late 1990s when the Internet was emerging and the API landscape was in its infancy. Inter-app communication frameworks like SOAP and CORBA exchanged data but were complex, lengthy, and often challenging to grasp.
The API landscape changed around 2000 when computer scientist Roy Fielding and his colleagues realized they could build a more straightforward and standardized solution on the Internet’s primary protocol, HTTP. Thus, the Representational State Transfer (REST) architecture was born. REST APIs revolutionized things by distilling operations to a core set of CRUD requests, including POST, PUT, GET, and DELETE. Companies like eBay quickly jumped on the technology as they embraced the new e-commerce frontier. Thus, the era of app integrations had truly begun.
From the mid-2000s until approximately 2014, REST APIs facilitated diverse interconnections. From online payment processing to the generation of support tickets and everything in between, developers harnessed this newfound technology to consume and share services with third-party entities conveniently. But just as the early pre-REST frameworks had their challenges, so did these integrations. Each integration was a DIY affair. Developers had to learn each third-party app’s API and create and maintain app-specific integration. And with the growth of SaaS, new integrations had to be made for new customers. It was all becoming much more challenging work for developers, but with new problems come new opportunities.
iPaaS or Integration Platform as a Service
By around 2014, companies were integrating with multiple apps, often building separate integrations for the same app to handle different scenarios.
Integration as a platform as a service (iPaaS) providers soon sprang up after seeing an opportunity to take over the burden of integrations and offer them as a service. This meant companies could now pay for a subscription to pre-built integrations rather than invest vast amounts into DIY integrations. iPaaS providers not only took over the mechanics of integrations but also provided additional functionality (e.g., workflow design, enforcing data standards, support for different protocols, customizations, etc.).
In recognizing the hard work developers were putting in, MuleSoft, a middleware and messaging company whose name was based on eliminating the donkey work, expanded into the iPaaS market. They became one of the early and prominent players in the iPaaS domain. They furnished app networks with pre-built APIs for diverse systems and a bus-like communication platform to facilitate interconnectivity. They also empowered developers to design APIs, dispensed libraries to share APIs, and introduced a console for integration management.
The API integration history landscape was also changed by Zapier, who shifted views on how automation could be achieved via integrations. Zapier effectively democratized iPaaS by being a no-code solution. For the first time, non-technical users could connect to apps and build integrations – a task formerly relegated to developers. Zapier built on its success by treating each integration as an official release and highlighting its value to its customers. They also made it easy to create multi-step workflows with two or more app integrations, and developers could start for free.
However, iPaaS offerings weren’t the be-all, end-all solution. They often lacked the functionality to handle complex use cases and still had scalability issues. For example, several integrations for an app were still required for different scenarios, a problem magnified when an app has to integrate with dozens or even hundreds of other apps.
At the same time, companies started looking beyond their internal integrations and how they could add integration functionality into their products. Through such embedded integrations, they could enable their customers to choose/configure how the product integrates with the third-party apps they use.
API Integration and iPaaS products
The concept of embedding iPaaS into products, termed embedded iPaaS, held great promise. This approach enabled companies to extend the power and flexibility of integrations to their clients, not only enhancing the capabilities of their products but potentially prolonging their lifecycle.
One of the challenges in API history was offering an embedded integration solution facilitating huge integrations and dealing with associated complexities like account management and large-scale customizations.
Around 2019, Tray.io, an established iPaaS provider, showed they could leverage their existing integration technology (e.g., their vast collections of connectors, workflow builder UI, etc.) and offer an embeddable solution. The result was Tray Embedded, and as the company states, it put “...the power of integration into the hands of end-users, via in-product, self-service experiences”. Additionally, their low-code solution offered a configurable white-label user interface, making the integration capabilities appear like native features seamlessly integrated into the application.
But as with iPaaS, embedded iPaaS solutions were generally best suited for connecting to only a few apps. They still needed to catch up regarding scalability, such as integrating with large numbers (e.g., whole categories) of apps, especially for complex integrations. Also, many of the no-code/low-code solutions lacked features favored by developers, including collaboration, version control, and various testing facilities.
Unified APIs history
Abstracting complexities to create a more user-friendly interface is a longstanding practice and a primary function of APIs. Around 2020, the concept of unified APIs gained traction. Unified APIs take abstraction to the next level by amalgamating the functionalities of distinct systems into a single, unified API.
The key player here was Merge.dev, who saw unified APIs as a way for developers to build several integrations of a similar type (e.g., CRM, HR, etc.). Merge emphasized the standardization of data, enabling developers to access it consistently. They also unified the authentication and authorization mechanisms across systems through a common token-exchange system. In a broader sense, Merge integrated numerous advancements from iPaaS and embedded iPaaS solutions into an alternative integration solution geared toward developers.
However, things continued to evolve. New players came onto the scene and questioned if there was a way to build a universal approach to integrations, one that could combine the best of iPaaS, embedded iPaaS, and unified APIs.
Universal Integration platforms - future of API
Built on combining the benefits (while addressing the drawbacks) of iPaaS, embedded iPaaS, and unified APIs, universal integration platforms emerged around 2022 and continue to represent state-of-the-art integration technology.
As a universal integration platform, Integration.app eliminates the need to devise and implement separate integrations. Instead, it focuses on integration planning. The concept of abstraction is built on by allowing more granular abstractions. Suppose your integration revolves around tasks, so you can design it around the concept of a task, its requisite fields, and the operations it requires. Subsequently, our AI-powered platform generates application-specific yet customizable code, enabling the scalability of integrations. Of course, there’s more to it than that, so we recommend reading Emergence of Universal Integrations: how SaaS build customer-facing integrations in 2023 for more information.
Integration technology has come a long way, and each generation has brought new advancements, opportunities, and problems to solve. Here at Integration.app, we believe that universal integration platforms are the future of integrations because they combine the best of iPaaS, Embedded iPaaS, and unified APIs.