A C-Level Introduction to API Composition

As the number of APIs keeps growing and headless services are on the rise, understanding APIs and API Composition has become a necessity for decision makers in almost any industry. The impact of every device, production plant, product usage and sales process being connected to the internet and generating an ever increasing stream of data is so profound that understanding the basic paradigms is critical to making the right strategic decisions.

APIs, or Application Programming Interfaces, are dedicated data interchange points that link different software applications together. This can be the case on a local computer, but also on different devices thousands of miles apart, all connected over the internet. A perfect example is in your hands every day: your smartphone, retrieving emails from a mail server, or displaying the local weather as provided by a weather service.

APIs allow applications to exchange data and invoke functions from each other to perform a certain task, such as “provide the weather for my location”. From an API perspective, your smartphone app would send a request containing your location to the weather service, which would then retrieve the weather parameters based on the given location and return it back to your app. All API conversations follow this “request and response” pattern.

So at their core, APIs enable connectivity, allowing various software components to interact, even when they're built using different programming languages or run on different platforms. It also means that software no longer needs to contain all the logic itself (hence called a software “monolith”), but utilize a variety of services to perform specific tasks. This is called a service-based architecture.

The benefit from a software developer’s point of view is obvious: rather than having to build everything yourself, which takes time and costs money and is equal to reinventing the wheel, you can simply focus on the added value of your software and connect external services which solve specific needs. This includes standard building blocks of software, such as authentication. And vice versa, if you build your application to include specific APIs, you can provide your service to others which invoke it through the interface.

It’s the digital representation of globalization and distributed supply chains: OEMs, like car manufacturers, usually buy many components from suppliers and then integrate them into their product, which reduces their level of vertical integration, especially in areas they have no expertise in, for example in manufacturing display screens or tyres for their cars. This example also clearly shows the need for one key strategic decision: where to integrate vertically and “own the stack”, and where to rely on suppliers (service providers). We will come back to this later.

One challenge with APIs is that they come in many types and shapes, also because their design has evolved over the years. Many modern APIs follow a standardized format, which is called a schema. This is like a standardized manual of how to work with, and what to expect from an API. But there are other types of APIs and protocols which govern exactly how the data is exchanged over the network. Also, security and stability are relevant factors and highly depend on how well APIs have been implemented.

This leads to a lot of work when developers are integrating APIs. The time needed for this as well as the risks involved when doing things manually, such as security flaws or performance issues, are the main reasons why API integration and management needs to be automated. This is especially relevant as the number of APIs to be managed keeps growing, and their data becomes a critical element of decision making. Essentially, it’s the reason why we founded WunderGraph.

Whereas API integration describes a process or technical task, API Composition is a paradigm that stands for the creation of added value by integrating certain services, functionality and data by means of their respective APIs to form a new service or product. The result is called a “service stack”.

This paradigm is closely related to the ascent of “headless architecture”. If you can build service stacks to form a new application, you can also de-couple all front-ends from their services to make them even more versatile and light-weight. The front-end is the so-called user interface, or “UI”, to interact with the actual service, accepting user inputs and visualizing the outputs (yes, a screen and keyboard also are a kind of interface :). Previously, every full-fledged application usually came with a front-end, but under the API Composition paradigm it’s only the functionality that matters, not the UI.

API Composition thus allows you to build your personalized service stack for your company and then add one seamless UI on top. Any specific functionality that you require can be added at different levels, depending on your needs. For example, your stack could consist of:

• A database
• An authentication provider
• A headless ERP system
• A headless CMS
• A headless ecommerce solution
• A bunch of legacy APIs (internal & external)
• A bunch of modern APIs (internal & external)
• An analytics suite

Of course, to make all this work, you need a “composer” like WunderGraph Cosmo for your API symphony of services in your stack. This piece of software is the facilitator required to bind your stack together, make it usable as one, add observability and connect your front-end and custom software.

API integration refers to the task of connecting APIs. API composition is building a stack of (mostly) headless services by connecting to their APIs to create a new service, product or entire ecosystem.

As you can see, API Composition is not just relevant if you are building software - it’s relevant to any business as we all depend on a host of tools and services to run our companies. It also makes a great difference to consumers of your services, in the most basic version as part of your ecommerce offering. API Composition allows you to present a seamless user experience across multiple systems, such as payments, shop, and content, where users would otherwise notice gaps or disruptions when following their customer journey.

If APIs are the building blocks of digital transformation, enabling different software services to connect and collaborate, API Composition is the strategy to leverage these building blocks to create sophisticated digital products with an excellent customer experience. At the end of the day, this will be the differentiating factor to stay ahead of the curve in innovation, growth and market share in the ever evolving digital landscape.

What you have learned so far are key cornerstones of the so-called MACH paradigm. This acronym stands for:

• Micro services
• API first
• Cloud native
• Headless

If you will, it’s the “meta stack” that describes how a lot of modern software products will be composed: you take some micro services that you’ve built API-first, and run them on a cloud-based system in a headless way for maximum flexibility.

So what is a micro service, and what does API first mean?

A micro service is the opposite of a software monolith. The picture in your mind straight out of the “2001 - A Space Odyssey” movie isn’t too far off here: essentially, in the past software has been built as one large chunk of code (I’m simplifying, but you get the idea).

The downside of this is that at some point, monoliths become unmanageable. If changes need to be made which touch core functionality, the cascade of side effects this may trigger - from interfaces/APIs to databases to error handling etc. - can saturate entire development teams for months, and even if they manage to stay on top of things, the monolith becomes a big bloated patchwork code block over time and has to be completely rewritten at some point (I’ve been there a few times; your CFO doesn’t like this).

With the rise of agile software development, it became obvious to even to the most convicted monolithians that a monolith is a thing of the past, and modern software development calls for more flexibility and smaller increments; not just in development, but also in output. Enter micro services.

“Micro” may be misleading, but it means that software is written as smaller programs which ideally perform very specific tasks - or “services”, for example signing on a user or rendering output for the website. These micro services all offer an API for connectivity to all other services, for example by means of an API gateway or any kind of message system that facilitates data exchange between the micro services.

As micro services grow, so does the number of APIs and the need to orchestrate this data exchange. Also, it now makes a lot of sense to not start with coding the service, but with defining the API.

This is a fundamental paradigm shift as most of the time, engineers will write the software and then think about data exchange, which holds a lot of challenges. It’s a little bit like the “design follows function” or “function follows design” dichotomy. If you truly want to build services that are interchangeable and interconnectable, you have to start with defining the API, which in turn defines what engineers need to develop.

By building micro services API-first, software systems become super flexible, easier to maintain, to document, to exchange, and faster to develop as you can split work naturally between teams - their window to the outside world is the API; that’s all they need to know.

So how do these rather technical things translate into something that’s relevant to you as an executive? After all, you have experienced experts taking care of this, so why bother?

Like a captain on the bridge, you still need to understand how a ship is steered even though you’re not the sailor at the helm. This cannot (and should not) be delegated.

Let’s look at four strategically relevant aspects in particular:

Any decision you make should be based on data–the more (instantly available) data you have, the more complete your understanding of the situation, and the more likely it is that you know more than your competitors. The way to obtain the data is through APIs, so it will be in your best interest to create as many API endpoints as you possibly can to generate that data.

Do you remember all the occasions when you asked people to provide a dashboard of certain data, but you got back a manually groomed Excel spreadsheet? You should encourage your entire organization to think “API first”: which data will be exchanged? Which data would you like to collect (within legal boundaries, of course)? By fostering this way of thinking, you will establish a mindset in your company that makes sure you get the most information out of any process or system you connect to. From my own experience, I know that people often focus on features first, and APIs or data generation comes in last when all design decisions have been made and deadlines have been agreed upon. Make sure the whole API complex is made a priority, everywhere, and don’t cut people short when API work adds to the timeline. It’s worth it, and you have to show that you care on the executive level.

By taking a modular approach, your teams will be able to ship and iterate faster, which gives you - thanks to the data at hand - better reaction times to optimize. Make sure to not go for monolithic approaches. If a project to introduce new capabilities takes longer than a few months to even ship a prototype, challenge the team if they are indeed following an API-first strategy, or if they might be affected by the not invented here syndrome .

Another advantage to understand is that you become less dependent on vendors of standard functionality. If you follow a composed stack, you gain the freedom of exchanging parts of it without having to rebuild the entire construct. Not happy with a service that you integrated? Replace it! Want to add more functionality? Add it!

The reason is that everything is abstracted by APIs, and your service composer such as the WunderGraph platform will be able to connect to different services easily. Of course, it’s also important that the composer is able to work with any services and is not limited in any way.

Should you be developing your own software, you may want to do it in a headless, or at least API-first way to make it a business model . Your product could become a building block of someone else’s stack, or - if not used externally - of some new product that you are building in house. In order for this to be possible, you need to make sure it’s designed that way right from the beginning, making it a core strategy.

Make no mistake: API Composition is no free ride to success. If you recall the automaker’s OEM example and consider the recent disruptions of global supply chains, it’s clear that each dependency adds its own risk to the stack. You need to decide carefully which parts of the stack you want to (or must) own in order to de-risk your operations. To remain within the automobile frame of reference, Tesla was able to thrive even during the supply chain crisis because they had a higher vertical integration level than almost any other manufacturer.

A good differentiator here would be how much choice you have to delegate a specific service you’ll need. The more options you have, the better, and the less likely you will suffer from disruptions at the chosen supplier. An API Composition platform like WunderGraph Cosmo will make sure that you can quickly replace any service that becomes a liability or falls short of expectations.

Another challenge is security. Interfaces need to be safeguarded, and it’s important to have a solution in place that delivers this out of the box when connecting all your APIs. Ideally, security is built-in “by design”.

Then, there is performance. At WunderGraph, we have made it our priority to build the fastest API Composition platform on the market, but even we can’t control how fast each individual service responds. This is why we have integrated failsafes to automatically decouple slow services so the overall stack remains fast and usable. This principle also applied to error handling. One single error on a specific API should not be able to bring down the entire stack, but this needs to be actively addressed by any API Composer.

As we look ahead, it's clear that API Composition will play a crucial role in shaping the technological landscape. Megatrends like artificial intelligence (AI), machine learning (ML), and the Internet of Things (IoT), all depending heavily on API connectivity to exchange data, will further drive the adoption of the API Composition paradigm.

In the realm of IoT, API Composition will be instrumental in connecting billions of devices worldwide. These devices expose APIs, which can be composed to create holistic systems capable of gathering, analyzing, and responding to data in real time. It’s possible that these stacks are fully managed by an ML/AI algorithm to decide which services to connect, and when to involve humans. For example, think about

If you’ve made it this far, you hopefully have a pretty good idea of APIs and Composable Architecture now. There would be so much more to tell, but this needs to suffice as a starting point. You will find many interesting articles about various subtopics in our blog, but first and foremost, you now can ask the right questions: where are we in the MACH journey? Do we think API first? What’s the place of our business in an API-driven world? Where do we score on the SWOT matrix with our digital products?

In any case, the simple fact that you’re asking yourself these questions means that you’re actively shaping the future of your company. Sometimes, awareness is all it takes to make a difference.