Before we can even begin to debate whether you’re better off with an API Proxy or an API Gateway we should probably describe what they are and what they do, and try to get to the fundamental different between them.
Gently paraphrasing Wikipedia a Proxy is something that acts as an intermediary, making requests on behalf of something else (there are some pretty good definitions in the terminology section of the W3C HTTP standard). What this means to us in the API world, is that when you’re using an API Proxy, your API had better already exist, i.e. while a Proxy can add some capabilities, like some basic security and monitoring, it really can’t do anything particularly sophisticated with content or routing, let alone transformation, mediation, or orchestration.
In simple terms you can think of the Proxy providing you a new endpoint for an existing API and adding some lightweight security and monitoring.
An API Gateway on the other hand provides a much richer set of capabilities. When you use an API Gateway to expose an API, you don’t even need to start with an API. You can take multiple existing services of varying types, and use the Gateway to construct a modern, well-structured API. The Gateway, of course, still offers the same capabilities that an API Proxy would offer for security and monitoring, but it takes these and other capabilities much further.
So given that the API Gateway is so much functionally richer than a Proxy, why wouldn’t you always use a Gateway?
Well, according to some vendors, Gateway products are slow and unwieldy, with complex configuration and poor performance. The truth is actually the opposite. A well-designed and implemented Gateway, like SOA Software’s, will automatically optimize its configuration depending on how it’s being used. It can act as a simple, lightweight proxy, offering exception performance, or it when needed it can offer comprehensive service orchestration, transformation, mediation, DoS prevention (including things like Anti-virus, and threat detection), along with incredibly rich content and transport security capabilities that go far beyond anything a simple proxy can offer.
But, I hear you saying, how do vendors with Proxy servers do things like SOAP to REST mediation? It’s simple, they write code that their customers have to support, or pay for updates anytime something changes. Using an API Gateway like ours you can turn your existing services into exceptional APIs with sophisticated security and monitoring enabled in a matter of minutes. Try that with a proxy and you’ll quickly find yourself investing a good few weeks or even months writing code, only to do it all over again every single time you need to make a minor change.
While a Proxy may be a good solution for taking the first few simple steps with a basic API or two, to meet real enterprise needs you’re going to need an API Gateway, but you’d better make sure you choose a Gateway that knows when it needs to act like a nice simple proxy…