Let’s start with a simple assertion – you probably aren’t building your API(s) in a vacuum. Ok, but what does this have to do with orchestration, and what is orchestration anyway?
I’m not going to try and get into a debate on what the term orchestration means, and how it differs from choreography, that subject has been beaten within an inch of its life in other places, with a good summary discussion here. Instead, I’m going to focus on how it can help you deliver excellent APIs.
An API is often going to be an externally facing representation of your business. It needs to be nicely packaged, documented, marketed, and supported, but like a birthday gift, no matter how pretty the wrapping, it’s what’s inside that counts. Your API needs to present a clean, elegant interface, built according to modern industry best practices (likely REST/JSON). The problem is that in most cases (back to our assertion), your API will be built on top of existing services that probably don’t offer clean, elegant interfaces, and rarely use REST/JSON. More to the point, if you look at that last sentence again you’ll see the words API (singular), and services (plural). Here’s where you need orchestration. You need to create a single API that offers valuable functions to its consumers, often by making multiple calls to multiple different services to respond to a single API request.
It’s easiest to explain this with an example. Imagine a media company (let’s call it MediaCo) that has grown through acquisition and now owns multiple different regional and genre specific content providers. MediaCo needs to publish a catalog of all its content (could be music, TV shows, movies, almost anything), but of course the raw information that would comprise the catalog is distributed across all of its businesses, most likely using different service styles, formats, policies and content.
This is where an API Gateway’s orchestration capabilities come in. MediaCo can design the perfect catalog API without having to worry about the structure, style and even content of the various services provided by each of its business, and can use API orchestration to decide how to service each request, and construct service calls appropriately. It could take a request for details on a specific catalog item, use a lookup service to find where this information is, construct a call to a service that has some of the needed content, and use the response or pre-programmed logic to construct one or more calls to other services to get more information.
It’s easy to see how this idea becomes much more powerful when you provide a clean separation between your orchestration (or process) and the styles, transports and policies of the APIs and services the process is exposing and consuming. See our article on the Anatomy of an API Gateway.
You do have to be a bit careful to make sure that you don’t try and overextend the capabilities of your API Gateway, recognizing that you do most likely have existing development and application platforms. But, that said, it’s nice to have the power and flexibility to use your API Gateway to meet some pretty sophisticated business needs without having to rebuild existing applications and services.