API Gateway – The Basics

It’s Tour De France season, and hence a lot of my time is being spent in watching the stages unfold on TV while the cyclists pedal away to their absolute physical limits. While sitting comfortably on my sofa watching the TV, I use the remote control regularly to increase/decrease the volume and some other operations too. And just like that, without even noticing I have interacted with an ‘Interface’. The buttons on the remote perform simple or complex operations but I am shielded from all that complexity and just have to worry about pressing the button at my end.

We are surrounded by interfaces. When I want to listen to my favorite song on Spotify on my phone, I click on the song and hit the play button. That’s an interface! I don’t know about the complexity of the play button, or the code written behind it. Neither am I privy to the code that is running behind to fetch the song and stream it over the internet and bring it to my device. And since this interface has interacted over the web, it can be called web based interface. And since this interface was used by an application (Spotify) and the construction of logic was done though a coding program (Java, Python, Ruby etc), this simple sounding interface takes the form of a jargon called Application Programming Interface or also known as API. The API that we discussed above would be called a web based API. And even though there are many types of APIs, web based APIs have become so popular that whenever we hear the term API out there, we can safely assume that the subject under conversation is web based APIs.

In simple words, APIs are like functions that we write in the code that get called by other applications in order to execute a particular operation

Keeping that in mind, let’s take example of an ecommerce application. A user can log into the application by registering oneself on the platform or via third party authentication sources like Google, Facebook, Outlook etc. Once logged in, the user can surf through the products, add them in the cart, check them out and complete payment in order to purchase them. Even though the user can surf through the products without logging in, but if one has to make a purchase, logging in would become necessary. On the other hand, the employees of the ecommerce company would also be logging in the application, but from a different route, assuming the admin role of the application once authorized, and updating/adding/deleting products, images, pricing info, product description etc.

Let’s think of these actions from application perspective. The users are accessing various URLs to see the home page, see the products, access their cart and add products to it. Similarly, the application admin is also accessing URLs to add, delete and update information about the products. On top of this, the URLs can be accessed from various devices like phone, laptop, desktop etc.

We also want to ensure that our web application is secure and hence would add SSL certificate to the application to secure web traffic. Our application so far would look something like this:

Now, our application has a lot of business logic code and then we have these three components of security, authentication and authorization which are not business logic related. We want to separate these horizontal components from business logic. And this is where API gateway comes into picture. API gateway is a component in this architecture which handles all the non business logic activities in order to execute API calls by other applications.

The requests call would now land on API gateway first. The gateway would ensure that the traffic is secure, and also rotate SSL certificates periodically if required. The gateway will pass the call to homepage and products APIs. If the user wants to call the cart APIs, the gateway will first check if the user has been authenticated. Similarly, if the admin wants to access the product add and delete pages, the API gateway will handle the authorization module for the admin. Post these checks, the gateway will then pass traffic to the relevant APIs.

This is the basic functionality of an API gateway: to consolidate and manage all the horizontal non business logic related activities which would front-end the APIs. Now once we have the basic setup in place, let’s explore which other activities can API gateway handle on top of these three:

Response Cache: Imagine if the ecommerce application has also deployed a recommendation engine on the home page which provides recommendation to users when they log into the website. These recommendations are updated once every 90 minutes. Now, every time the user comes to the home page, a call would be made to recommendation engine module and recommendation would be pulled. But for a period of 90 minutes, the recommendations would remain the same irrespective of number of calls made to the module. API Gateway has a response cache feature in which we can set the cache period time for an API response so that unnecessary calls can be avoided to the API. In this case, we can use response cache for recommendation engine and set the time to 90 minutes. This way the gateway will not make repeated calls to the recommendation API and instead pull the results from its cache. This will result in lower latency.

Static Content: Similar to the above use case, there are many static files on the website that do not change with time. This might include parts of home page, contact us, about us etc. API Gateway can store and serve this static content directly instead of making calls to a separate module.

Routing: The ecommerce application could have different APIs for mobile and desktop. In native mobile applications, there could be different APIs for android and iOS apps. API Gateway can handle this routing at its end by understanding the device from which the request is coming and forwarding it to the corresponding APIs

Load Balancing: If there is a popular service on which numerous API hits are received, there could be multiple copies of the service deployed to handle the traffic. In this case, API Gateway would automatically balance the load across various copies of the service as and when it receives requests for the API.

New Deployments: Whenever the newer version of a particular API is launched, API Gateway can be used to manage deployment to the new version. API Gateway can be used for rolling deployment, blue green or canary in which the gateway would send traffic from older version to the new version as per the deployment strategy.

Exposing public APIs: Imagine if one of the APIs of the ecommerce application became so popular that the organization decided to make the API public and available for others to use. It could be the recommendation engine API or Payment Gateway API that the organization developed and now it is being used by multiple organizations. In this scenario, API Gateway can be used to manage the billing and security of the API. The gateway would calculate billing for each organization that is using the said API on the basis of number of API hits received from them. API Gateway can also be used to limit the rate at which the API is being called from a particular user. This could be done to ensure API is available for other consumers, or if spamming is suspected from a particular user.

These are some of the features and use cases of an API Gateway. There are many examples of API Gateway providers in the market. If you are deploying your application on a VM and would like to manage the API Gateway yourself, you can look at deploying Apache, Nginx, HAProxy and Spring Cloud Gateway. Otherwise, if you are looking for a managed API Gateway, then you can look at Alibaba Cloud API Gateway, AWS API Gateway, Azure API Gateway, Google Cloud Endpoints and APIGEE.