Is it one API or multiple APIs? From the consumer perspective, it’s often one API that they consume but in the background there might be APIs from multiple sources that need to be called, coordinated and where requests and responses need to be split, merged or routed, this is called API Orchestration. The growth of microservices also encourages the need to have multiple APIs combined to make it easier for consumers.
I like to use examples to explain this API Orchestration topic. It’s pretty much a topic for “API Providers” but this is also interesting for App Developers, I’ll explain why.
Composing API Experiences
Imagine you have the task to create an API that contains all data needed to show a smart or connected car on a map. Which services do you need to do this? Quite a few actually.
- First, you would have to check the user and validate if it’s actually his car and that he’s authorized to do this query.
- If you monetize this localization service, you also want to check that he has a valid subscription.
- If the checks turn out ot be ok, you need to call the backend system that contains information about the car itself like its current location with latitude and longitude.
Those are already three services and likely multiple methods that would have to happen resulting out of a single API Call.
Now inside the App the developer is facing the challenge to take this information and do another call to a Maps API like Google Maps API providing the GeoData he has just received in order to display it on a map.
Wouldn’t it be better if the API Provider had integrated with the Map Service already and would have directly provided the map data into the response? One call saved, one burden taken away from the mobile app developer.
In this case, such an integration with a partner or external API also allows to keep control of the integration, as the API Provider is able to switch from one Maps Source to another depending on quality of service, costs etc. without letting the App Developer know or without requiring change on the mobile app itself.
All this together can be seen as one experience delivered via a single API.
What is needed for an API orchestration?
To do a sophisticated API Orchestration like in the above example there are couple of things needed.
The system doing the orchestration needs to be able to handle multiple identities to call the different backends. In some cases where the API is not open, there is a need to verify the caller by checking API keys, OAuth or SAML tokens.
Depending on inputs and requests, the calls will need to get routed to the backends and also the responses will need to get routed to the initiator.
Incoming calls will look very different from what backend APIs will require, so the payload needs to be able to be decomposed and transformed. The backend response sometimes needs transformation too. The consumer usually expects a composite or merged response. This is also called API mashup.
Not only in complex systems but in general, API calls trigger compute power, which is expensive. Caching helps reduce the load, keeping a copy of the last response in memory, serving it way quicker than going all the way to the backend. Caching is not possible for all API calls but for things that are quite static or very heavy, caching can be a good help. There is also the API streaming technology that makes sense to reduce compute power.
Ideally these building blocks can be combined in multiple ways and used as building blocks in repeatable manner. To learn more about API mashup, check out this article about what is MASA – Mesh app and service architecture.
Gains you will be able to achieve
By using API Orchestration, you for sure have to invest into the setup and operations of such a system. With having a system in place that does the API orchestration, you have a single place where you control and enforce the rules of the API ecosystem.
Quite often, visibility into what’s going on is a nice side effect. Speed is another gain and advantage when caching is used the right way helping improve the customer experience. For developers, it will be much easier not to do 5 calls to get to the result they are expecting but one.