A new blog post by Subbu Allamaraju discusses drawbacks of the current APIs implementations and ways to improve them.
According to Allamaraju, the following are the main problems that an API user is facing today:
The interface mismatch. Because APIs are created by a provider, they typically reflect the producer’s point of view - maximize use and reuse is the most common feature across all consumers APIs. This typically leads to creation of fairly granular APIs that allow every consumer to invoke any subset of these APIs in any sequence to fulfill his goals.
In this process, [the provider is] bound to tradeoff special requirements of consumers and try to stick to a common denominator. This creates a mismatch between what the consumer needs and what [the provider is] offering.
Writing client code is slow, repetitive and verbose. Using granular APIs generates multiple API calls results of which need to be aggregated.
Unless you got canned SDKs for these APIs, writing code to make 2*n HTTP requests and process the responses can take a while.
On top of that, for every API invocation, a client also needs to build requests and parse responses.
Getting enhancements from a provider slows one down. Because API providers support many consumers and work on their own schedules, that are often quite different from consumer’s schedule, it is typically hard to synchronized specific client’s requirements with provider’s schedule. Moreover, because providers are typically measured on API reuse, building one-off API for a specific consumer is typically hard to justify..
API requests are often chatty. Executing a chatty client, one making multiple HTTP calls, usually leads to both significant performance degradation and network over utilization. It is intuitively obvious that from both performance and network utilization point of view, using a less granular APIs is a better approach.
Consistent RESTful APIs don’t matter as much as we think. Although ideally it would be nice to see consistency across APIs implementation, the most important feature an API should provide, according to Allamaraju, is interoperability:
I would rather spend my time enabling interoperability than preaching for consistency.
Summarizing, Allamaraju noted:
The [main] client app’s challenges are aggregation, parallelization, and orchestration of forks and joins.
So how can this problem be solved? Allamaraju mentioned that
...at eBay, my team has been working on a new platform to simplify use cases like the above:
- Bring down number of lines of code to call APIs
- Automatically orchestrate API calls as needed
- Create new consumer-centric APIs that wrap existing producer-centric APIs
- Cut down bandwitdh usage and latency
Allamaraju is not the only one suggesting such a platform. During QCon SF, Daniel Jacobson from NetFlix presented a similar solution currently implemented there.
The solution proposed by Allamaraju and Jacobson make perfect sense, but one has to wonder what is different from Enterprise Service Bus (ESB),that was touted as one of the main reasons of SOA’s failure? Or the problem was not ESB but its improper usage? Or was it a generally good pattern that now is getting a second chance?
