Ian Goldsmith

There are quite a few products on the market that are billed as API Gateways; many offer similar capabilities, often delivered in markedly different ways. So let’s take a look at how we at SOA Software believe an API Gateway should be built, and why you should care about the way your API Gateway works.

Most API Gateways operate using a proxy pattern, where the Gateway listens for incoming API requests that it routes to a service exposed by an application. This is often deployed in a customer’s DMZ with the API endpoint exposed to the outside world, and the application exposing the service buried deep inside the customer’s network. The Gateway will mainly be responsible for adding non-functional capabilities, ranging from securing and monitoring the API, through routing, transformation, mediation, and much more. How useful and flexible the Gateway is will depend on how it delivers these non-functional capabilities for the APIs it exposes, and how it is built to satisfy its own non-functional and functional requirements.

There are a couple of rules that many of the vendors break:

  • They mix business and non-functional requirements together in the same architecture
  • They describe the complete proxy implementation as policy

One of the most important principles we follow with our API Gateway is the separation of process, binding (style), transport, and policy; and the resulting ability to declaratively define APIs.

In this model, the Gateway defines the API as an abstract interface implemented by a process with input and output messages.  In many cases the process will be nothing more than a simple invocation of a service exposed by the application mentioned above (more on processes in another discussion).  The Gateway can define multiple different API styles (REST/XML, REST/JSON, SOAP, etc) for this abstract interface, and can expose each of these styles over multiple different transports (http, https, WebSockets, JMS) or networks.  It can then enforce (and implement) different policies for each transport, style or message, as well as the global policies that can be applied to the entire API, or all styles, or all messages, or…well, you get the idea, there’s a ton of flexibility in how and where you instruct the Gateway to enforce policy.

There are a few key points I want to highlight here:

  • We ensure flexibility by keeping styles and transports separate from messages and process
  • We keep policy out of the process to reduce complexity
  • Processes, process steps, and scripts are architecturally the same

The use of policy to describe non-functional requirements is actually a big differentiator between our Gateway and many of the others.  By ensuring the separation of policy from process, message, style and transport, we allow our customers to define policies as reusable business assets that they can associate with multiple different APIs and services, rather than monolithic objects that have to be rewritten for each service anytime a business requirement changes.  For example if you have to comply with a new industry regulation requiring that a certain class of PII be encrypted, you’ll really appreciate the ability to use and share a single policy across all the APIs, messages, styles, and transports that expose this data.

One of the real beauties of this architecture is that the separation of policy, process, message, style and transport applies to the downstream services as well as the API.  This means that it’s incredibly easy to take an internal SOAP service on a transport like JMS using complex WS-Security policies and expose it as a RESTful API with JSON content secured by OAuth over https, and you can do this without writing a single line of code, or suffering through a complex integration process.  Furthermore, if something changes on the internal service, it’s a simple matter of telling the Gateway what changed and letting it do the rest.  Or if you need to add another transport or style (or both) to your API, the Gateway will do it for you with a couple of clicks of a mouse.

This post is the first in a series that will talk about how API Management platforms work, and the right way to deliver an API to your developer community.  Future topics will include things like API orchestration, scripting, policy, developer portals, OAuth, and much more.  If there’s anything in particular you’d like us to get into, please let us know.

Share Button

Add a comment