Weighing the Pros and Cons of API Chaining

From the very beginning, developers have sought to make their systems run more efficiently, delivering greater amounts of data and functionality in a slimmer, more useful methodology. Increased efficiency usually equates to money saved, so there is a very real drive behind the constant need for condensing and code tweaking.

Though there are a variety of approaches taken towards this end, one method remains a popular suggestion — API chaining. A simple process in theory becomes one more complex in application — with interesting results in certain use cases.

Today, we’ll discuss what exactly API chaining is, and how to implement it. We’ll take a look at the various strengths and weaknesses of this approach, as well as highlight some use cases that would benefit from its implementation. We’ll also compare it to a chief alternative competitor, GraphQL, and examine whether or not one comes out on top.

What is API Chaining?

Chaining is the act of initiating multiple data requests to various parameters, APIs, or microservices, in a single call. The idea is that by combining these requests, your platform gains efficiency and speed. However, there are some caveats that we’ll discuss shortly.

With API chaining, APIs are given client strings of varying lengths and purposes. These strings are then batched into a single request/response schema in an automated way.

One way to consider API chaining is to think about how mail is handled via the hub-and-spoke model. When you write a letter, this letter is dropped off in a post box. The postman then collects these letters and parcels, binding them together for processing. At the processing shop, these bundles from everywhere in your city are bundled together into even larger crates depending on their destination and purpose.

Chaining works much the same. The big benefit of this method arises in that postal metaphor — the joining of unrelated resources within a single action.

Let’s say you have a collection of APIs in a microservice architecture, each manipulating data across a suite of applications. While there is no need for a music discovery application to access the contacts on an iOS device regularly, say a new update has enabled a significant social networking service on the discovery application.

Luckily, your users also largely use another one of your products, a video sharing app akin to Vine, with users collated from their contact list. While pulling straight from the contact list and comparing to accounts might get you some users, you are likely to have a much greater chance of adding new users to your new social platform that already actively use your suite.

With API chaining, a request can be made to the video sharing application API to issue a friend request on behalf of the user, while avoiding sending new requests to users who are not represented on any of your suite’s applications.

In this case, what would typically take several calls — a “is this user on the video app?” call, a “are they on the user’s contact list?” call, and finally a “friend request sent!” call — can be condensed to a singular call.

Benefits of API Chaining

There’s quite a number of benefits to this approach in particular. First and foremost is speed — when an API only has to issue a single call that is handled by the relational processing between microservice APIs, calls are returned quicker and with greater accuracy. Light can only travel so fast, and thus processing is fundamentally limited — reducing the number of calls that must be made reduces latency, making chaining a powerful way to optimize APIs for mobile apps.

In the same vein, chaining is much more efficient than traditional calls. By using the connection between APIs rather than creating a singular “filter” or “intersection” style API that attempts to combine all calls after they’re made, you can perform the same function while not creating bloat inside your ecosystem. Chaining is the world’s greatest game of telephone — you ask your neighbor for sugar, milk, and eggs, and they in turn ask their neighbor for what they don’t have, and so on, until you get what you need — without this, you’d have to walk to each neighbor individually.

There is of course an implicit increase in security for this function as well. While it seems counter-intuitive, what with more resources being accessed with only a single call, the end result is a reduction in attack vector for the simple reason of having less calls.

This mode of combined communication also has the benefit of making the API more friendly to automation. By moving the logic of the call to a higher level, and opening the call itself to shared resources, the ultimate result is an easier to deploy, more automatic, less code-heavy, and faster solution.

What this all means is that, as long as it’s properly implemented, both the provider and consumer can have a more streamlined experience. While consumers benefit from combined calls and more simple call structures for large amounts of data, the provider has a much reduced amount of documentation and data bandwidth implications.

For more on API Design see our Design Insight

Drawbacks of API Chaining

That’s not to say, however, that the concept of chaining is perfect — there are some caveats to consider before implementing this methodology.

The first and most dramatic possible drawback is the fact that chaining lends itself to circular logic, if you’re not careful. Because multiple resources are being called, and many of these resources can be augmented by calls, it is possible to call a chain that results in an infinitely changing result.

These unexpected results can be negated, of course, and much of the drawback of circular references can be converted into a net benefit with proper redirects and interceptors, but the threat is very real, and easy to fall into if not mitigated from the onset.

Another is lack of support. Unfortunately, chaining is simply not supported by common and publicly used schemas and API patterns. Because of this facet, where communication logic and business logic are separate and architecturally limited, an API must be redesigned at worse, or augmented with abstraction layers at best, which can in turn negate many of the benefits inherent to the system.

Adding complexity to the call can mean a greater barrier to users and additional developers. With this also comes the risk of easier denial of service attacks and other such attacks that can use the increased ability to make combined calls to break the system.

This can be negated widely by simply enabling rate limiting, but all in all, it may be a negative that makes implementation not worth it.

Use Cases

Chaining is a preferred methodology in some limited circumstances. Since the circumstances themselves are often specific to the application, we must speak broadly as to the qualities that make API chaining a good choice.

  • Unrelated Databases: When multiple databases are present with typically unrelated data, and data must be pulled from both to form a relation, API chaining is best used. While it would be best in some cases to create a relational link between these databases, the problem arises in the frequency — if the data is not expected to constantly be referenced in a concrete way, API chaining can get around this problem with relatively low overhead.
  • Unexpected Data Requirements: When the specific requirements for a function or the given evolution of a product are unknown, chaining can cover this facet. Because not every facet of evolution in an API can be predicted, developers often suggest microservices as a solution. This is fine, but it limits the choice of development tracks into the realm of what already exists and forces concrete development relations. Chaining can eschew this.
  • High Volume Calls: When high volume calls are the name of the game, chaining can reduce the total impact of the simple volumetric issues by combining calls into single returns. This also has the added benefit of more secure communications, as the number of calls is reduced. While this could be touted as a feature, unfortunately, reception of chaining has not been as widespread as before, meaning that security in the API space doesn’t always flow over into chained requests. This can be negated with training, however.

Alternatives — GraphQL

This isn’t the only solution to the problem of such complex calls, of course. We’ve devoted much attention to GraphQL on the NordicAPIs blog lately, and have highlighted how effectively it manages data querying.

This can be used to replicate much of the effect gained from chaining, albeit via a different methodology. Because data can be defined via the GraphQL query, multiple data points can be collated into a single database or collection and then returned in the requested format for easier parsing.

For example, this call queries multiple endpoints through a singular call:

Since this is done using a completely different methodology, some of the benefits of chaining — specifically the reduction in call volume and processing — are lost. The architecture itself is simply being masked with GraphQL — none of the processing is changed on a base level, and a traditionally poor processing architecture can march on unbeknownst to the user.

While multiple endpoints are brought into a single endpoint, the result is still functionally the same — multiple calls are still called. The only difference is in the perception of the returned data and latency in returning that date.

There is a big benefit in integrating GraphQL, however, in the fact that the data can be pre-formed and pre-determined by the requesting entity. Whereas chaining simply returns the data for interpretation, GraphQL specifically issues a schema for data display, thus controlling the output more effectively.


API chaining is very powerful, but quite problematic when not properly implemented. Because of this, it’s often said that using chaining is outside of best practices, both due to lack of training and the avoidance to call through a proxy loopback.

It’s not within “best practices” for an untrained pilot to fly a 747 — that doesn’t mean the 747 isn’t useful to those who know how to utilize it. Neither argument is really one against implementation — they’re best categorized as perhaps strong precautions against poor implementation.

Though many of the criticisms against API chaining are valid, they can be negated by proper implementation. The choice to use API chaining will depend entirely on your circumstance and the needs to the application itself. In the right situation, with the right user base, API chaining is incredibly powerful.

This article’s intent is to describe API chaining as a general practice for API development, not to endorse a specific product, service, or open source project. Any concerns to the contrary can be made to Agnes Andersson Hammarstrand, Nordic APIs’ attorney at Delphi Law Firm in Sweden.
Nordic APIs

About Nordic APIs

In 2013, Nordic APIs was formed to help organizations become more innovative, lean, and efficient. Nordic APIs has grown into one of only a few all-API-related event series held anywhere in the world, and it’s the Nordics largest international community for API practitioners and enthusiasts. Through the global reach of our blog we’re connected to tens-of-thousands of API practitioner from around the world.

  • orubel

    For the record, comparisons against GraphQL have been made and GraphQL is far slower as it creates a TOOL LAYER that is unnecessary rather than an abstraction of logic which is what ‘API Chaining(tm)’ does with shared I/O state and API abstraction.