There’s a interesting post over on the Apigee blog this week on the role of API proxies for Web App development (“Why modern applications need an API proxy”) and it’s a great opportunity for some debate. (We actually left a comment on the blog – but it seems it hasn’t made it onto the page yet – hopefully it will shortly. Update: comments now back using disqus – thanks Apgiee team.)

Apigee provides a great service and the team is certainly right that many of the elements of infrastructure we see today in the “Browser Web” are emerging and will continue to emerge for APIs – analytics, access control, management, security, caching as well as others such as metering and billing.

However, as you might guess, at 3scale (since we provide a completely proxy-less solutions for API Analytics and Management) we have a slightly different view on the idea that a proxy is the key piece of infrastructure needed to provide these services :-).

The example of Google Analytics is actually a great one – if Google Analytics had required all the Web traffic it processed to pass through a Google proxy, it’s a fair bet to say it wouldn’t exist today as service (or even function in a half way reasonable way). In fact it was smart on the part of early analytics services to realize there was no need to monitor the traffic “in transit” but that instead they could monitor at one of the end points (the server or – in the case of Google Analytics – the client).
Pumping all this traffic through a proxy would likely have slowed down the web browsing experience significantly, created huge traffic loads and unpredictable single points of failure (all of which are arguably even more critical for APIs than they are for Web Browsing).

API management services (including analytics, key management, limit tracking and others) are arguably much the same. While a proxy based approach has some advantages (caching for example) proxy-less solutions are massively more scalable and flexible to set up:

  • They can be introduced with no impact on the API user experience since they can act out of band.
  • Infrastructure costs are significantly lower than for approaches which filter all traffic.
  • Many web companies already have well tested traffic handeling infrastructures – which makes adding a further proxy layer a wasteful repetition of cost.

Just as with current (Browser Based) web it seems likely to us that the majority of API traffic will also flow primarily on “the fast path” directly between the API provider’s servers and the consumer of the data (be it another Server, a mobile device, an aggregator or something else). The advantage is multiplied if using API management systems which function asynchronously with the management infrastructure (as 3scale’s do) so you can cache live keys, batch up reports according to any schedule and further protect against failures).

It’s certainly the case that some content (API and Web traffic) makes sense mediated through a proxy infrastructure – CDNs and security filters are likely to be relevant to APIs as they are to normal web content. Services like GNIP look like an excellent development for this. However just as in the web today CDNs are significantly larger built out global infrastructures rather than fixed location proxies and further they tend to give the most return to really the largest / highest traffic sites such

For security issues also, in some cases proxy can provide an extra layer of filtering before traffic reaches the origin server of the API. However they introduce the potential risk of the proxy infrastructure itself being attacked (and taking down
all APIs mediated through the proxy) and it’s possible to secure an API without the need for such traffic filtering.

So we think this is certainly a great debate – an both technologies have their strengths and we’ll see them play a role in API infrastructures. For now though if you’re convinced you need a proxy, give us a call and we’ll show you why in many cases you don’t need one – and we can cure your proxy addiction :-).