Alistair Farquharson

There is an excellent post on Kin Lane’s API Evangelist blog about The Battle for your API Proxy. I think a better title would have been ‘The Battle of Agents vs. Proxies’.

Agents have been around forever in one form or another. When used to deliver API services, API agents are different than proxies because they are in-process, and in the path of the transaction – you don’t have any redirection. Steve Willmot, 3scale’s CEO, describes their agent-based approach as ‘proxyless by design‘ and does a great job of explaining the benefits in his recent response.

In fact, API agents are good because they allow the API provider to present the orignal endpoints to the consumer, without introducing network latencies and unwanted third-party dependencies. However, there are a couple of downsides. First, they are too late in the architecture to provide features such as effective caching and DoS prevention. They also present a challenge because they complicate change management in the Development/Operations lifecycle of the provider application, requiring constant upgrades and release conflict management.

As Kin pointed out, Mashery and Apigee take a different approach, what he aptly calls “Proxy Flow Through”. Proxies are certainly less complex from a Development/Operations perspective and can offload processing (Authentication, Authorization, Monitoring etc) from the API providers infrastructure. However, they introduce potentially undesirable security risks, especially for enterprises where PCI/PII compliance are required.

What if you could take advantage of the benefits of both approaches? Put half of the solution on premise, and half in cloud – a hybrid deployment approach. This allows a local proxy to be deployed on premise, but put the administrative console and API management activities in the cloud.

This allows API providers to find their ‘balance point’, between what they deploy on premise and in the cloud, and to adjust it as technical considerations – and financial considerations – change.

Share Button

One Comments

  1. [...] goes into more detail in his blog post but the SOA approach is to marry the benefits of a proxy-less API service (SOA calls them agents), [...]

Add a comment