How do API Gateways work?

Question

How Do API Gateways work? What are the typical components of an API gateway? Are there common standards around how they manage security, call logging and governance?

Answer 1

The concept of API Gateway is more easy (to me) to understand with an analogy. If you think about a reception desk at the front of an office building, it basically routes calls, stops unexpected visitors and makes sure parcels get to the right place.

That's exactly the role of an API Gateway in a distributed application. It takes request and redirects them to the right service. Put into an image, here's how it could look.

Basically, it's the reception desk, between your microservices and the different clients requests (browers, apps, etc.). In terms of how they work, what are the components, and so on, it totally depends on the implementation and requirements. Some API Gateways handles authentication and authorization, others process and validate input data, or transform the responses. Some provides monitoring information, and some it all.

If you are looking for more technical responses, Steve provides great details on the different components that constitute such a layer.

Answer 2

This is a pretty wide ranging question since there are a lot of different types of gateways (and management solutions). In the broadest sense a gateway is a filter somewhere in your web stack (hosted by you or a third party) which filters your API traffic in someway. Some of the filtering could happen:

• Within a CDN if you're using one before it reaches your servers.
• Within a proxy hosted by a third party which you redirect traffic through.
• Within dedicated machines in your own cloud or local infrastructure which run proxy software (third party, open source or in house).
• Within a specific part of your application stack before traffic is taken for primary processing.

Typically the types of functions the gateway may provide may include: access control (filtering traffic so only authenticated/authorized traffic gets through), rate limiting (restricting how much traffic can be sent by each client of the API), analytics/metrics capture and logging (tracking what's going on on the API), security filtering (checking the content on incoming messages for attacks, redirection/traffic routing (sending traffic to different endpoints in your own infrastructure depending on the sender or the request).

The gateway typically works as a set of modules and filters which treat the traffic as it flows through it at high speed and you can typically enable those modules / filters you need and control their parameters. There are obviously quite a few different ways to actually do the implementation + various vendors and open source systems to choose from.

I'll try to write this neutrally since I work for 3scale which provides both commercial and open-source solutions but I'd enourage you to look at the various options and draw your own conclusions! The main choices you have are:

• On-premise proprietary gateways, from vendors such as Apigee and Layer7 - these are typically a hard or soft appliance you install locally in your data center.
• Cloud hosted gateways, from vendors like Mashery, Apigee, and WSO2 API Cloud which effectively have API traffic redirected through their servers to function.
• Plugin/Agent architectures, like 3scale (which I work for) which provide software modules that can be deployed on premise within the application, on premise within an open source proxy gateway like Varnish and also connected to a CDN.
• Open source solutions such as APIAXLE and WSO2 which can be deployed on premise or in the cloud.

The different approaches work differently and it depends what you're aiming for. At 3scale we obviously have a bias for our approach since it allows you to slot in the filtering agents pretty much anywhere in your stack - but no doubt every vendor will have their view!