Remote APIs, such as web APIs, can be complicated. They’ve got many concerns. How do you handle authorisation and authentication? What’s your versioning policy? How do you deal with a rogue client? What about mobile clients? Programmatic calls? Calls from the web? Caching? Reporting and analytics? The list is endless!
API Management became a thing. What if there was a way of centralising these responsibilities so that individual APIs could focus on the business logic? Companies started being formed and products started emerging. Two very popular tools to do this were Apiary (acquired by Oracle) and ApiGee (acquired by Google). There are also some open source packages too, such as Ocelot.
An example of one of these products became known as an API gateway.
An API gateway is a server that acts as a “front-end” for an API. It receives requests, enforces policies and forwards appropriate requests to the service. By virtue of being a proxy it can provide functionality to support authentication, authorisation, security, audit and regularity compliance. It helps insulate the client from the implementation details, deal with versioning and reduce the number of requests / round-trips by aggregating queries. There’s a great description of the pattern here.
This might sound suspiciously similar to a service mesh — both technologies sit in the middle of bits of business logic and layer some functionality on top. What’s the difference?
Before we look at that, let’s define some terms (more here) that might help.
· North/South communication refers to traffic flowing in and out of the data centre/network.
· East/West communication refers to traffic flowing between devices within your data centre/ network.
These are clearly two different types of communication. For North/South communication my clients could come from anywhere, whereas with East/West communication it’s on my network and has a certain level of trust.
API Management tools (such as API Gateways) really comes into the fore for North/South communication — when I’m bridging between the great big scary outside world and my internal software.
Service mesh technology excels for East/West communication where I can use technology like mutual TLS to establish trust between components I own.
So, what can these tools do?
Azure’s API management is well documented. The list of policies is comprehensive and gives a flavour of what API gateways can do. Everything from access restriction (e.g. setting quotas) through to caching and transformation is available. This is supremely powerful — imagine if you have a legacy system that returns XML. Rather than having to write clients to deal with that, you could apply a transformation policy at the server to turn that into JSON. In a similar vein, the error handling allows you to build common processes in place at the gateway, rather than having to write that into each and every client.
Ocelot allows you to do request aggregation. For example, you might have a new mobile client and want to combine two existing calls (let’s say “GetGames” and “GetScores”) so you can minimize round-trips to the server. An API gateway can handle this for you without changing any code on the original. Essentially, a bit of configuration and then you can write a custom function that groups the two responses together in anyway you would like. Pretty awesome!
Tyk (an open source gateway) provides some neat features to mock endpoints. This gives you the ability to define the APIs in the gateway (and write appropriate front-end code) without even implementing the back-end service. Great for rapid prototyping.
Apigee demonstrates how an API gateway can help make data driven decisions about how your APIs are used by tracking all calls and providing a management dashboard.
I hope that by reading this you now have an idea of what an API Gateway is, some of the reasons why it might be useful and why it’s not the same as a service mesh!