What is an API Gateway? | How it Can Actually Deliver Practical Results

"The term API appeared way before the World Wide Web. More recently a new term appeared: API gateway. It sounds a bit strange at first as the API concept in itself already suggests a gateway."

I’m so glad you asked! You might recall the term API appeared way before the World Wide Web and you hopefully know API stands for “Application Programming Interface”.

But more recently a new term appeared: “API gateway”. It sounds a bit strange at first as the API concept in itself already suggests a gateway. It might leave you wondering “what is an API gateway?”.

In a nutshell, an API gateway is a management tool that sits between a client and a collection of backend services, each with its own API.

Therefore, the API gateway acts as a single point of entry for a defined group of APIs. The client, in this case, will normally be an end-user application.

From a more technical point of view, you can also look at an API gateway as a specialized reverse proxy that can make different APIs appear as if they are a single API.

The “API gateway” term is often used in a microservices context. The granularity of APIs provided by microservices is often different from what is needed. This simply results from the microservices concept: there are several small pieces doing small different things.

Microservices typically provide fine-grained APIs, which means that clients need to interact with multiple services. For example, a client needing the details for a product easily could need to fetch data from numerous services. That is why an API gateway makes sense in the microservices world.

In this context and within a microservices architecture, again the goal of the API gateway is to present a single-entry point for all clients, but in this case, this is done mostly by simplifying the API presented to clients.

API gateway architecture

In this diagram, you can see an API gateway is sitting at the edge of systems. It acts as a management tool or middleware that mediates between a client and a collection of backend services.

These backend services can change location, architecture, and implementation (language, framework, and others) with minimal impact.

You don’t need to limit yourself to a microservices API gateway view, although it is what you could call the “classical view of an API gateway”.

You can also look at an API gateway in a more architectural way and see it as a design pattern. We can say the API gateway pattern is two-fold as it actually corresponds to two classic Gang of Four design patterns: the adapter and the facade.

Like an adapter, it allows for communication and collaboration even if the interfaces are incompatible.

Like a facade, an API gateway encapsulates the application’s internal architecture and provides an API to its clients.

Both in the microservices view and the architectural view, the API gateway always has an orchestration role and, in the end, should be there to make things work smoothly. But how can you move from concepts and definitions to results?

Let’s dive into more practical aspects and see how we can get results.

For this we will use a specific API gateway, our own integration gateway called Connect Bridge. Think of Connect Bridge as a single-entry point that “talks” SQL. This means that whatever code is used (and you can go for any programming language) it will communicate with this API gateway as if it were a database, through the normal CRUD statements: SELECT, INSERT, UPDATE, DELETE.

Connect Bridge has a “translator” (which we actually call “connector”) for each application we want to reach via the API. This connector effectively translates SQL statements into API calls.

By using Connect Bridge, you will need less code (way less – the reduction can be of as much as 90% depending on the project), the code will be easier to understand and test, and you will significantly reduce the number of bugs.

The funny thing is that when you are working with Connect Bridge, the fact that it uses SQL will make you think you are working with the target’s system database, for example, Microsoft Exchange’s database. But don’t worry, you are not, and the database integrity is safe – it is a gateway and always accessing the target system via its API.

Step-by-step with Connect Bridge as an API gateway

1. Code of your new or legacy application
2. CRUD statements in standard SQL accessing the target system as if it was a database
3. Connect Bridge translates SQL into API calls
4. For each target system this translations is actually handled by a connector

A note on what programming language you can use with Connect Bridge. As I mentioned, you can use practically any programming language.

You just need to make sure it supports ODBC, JDBC, or Web services. As long as it does, you are good to go.

For example, let’s say you want to use Java. Fine, then you can generate a JDBC Connection String, and there you have a Java API gateway.

Do you want to use Node.js? That’s also good, you can generate a Web Services Connection String and you have your Node.js API gateway.

I could go on, but I think you got it by now: you can go ahead and use your favorite programming language.

Connect Bridge is a paid tool, with prices varying in terms of the number and type of connectors used and the number of users. For you to have a general idea of this API gateway cost, we can tell you prices start at 150€/month. For more details on pricing go here. We recommend trying it out yourself with the free trial first and this way you can have an idea of what the gains in productivity will be.

In terms of ROI, you should also consider that the gateway ensures the final solution keeps working even when the target system is upgraded with no change whatsoever to the code you wrote. All the trouble will be handled by the gateway.

To walk you through the first steps with Connect Bridge, we will need an example target system. We will pick Microsoft SharePoint for that, but it could be many others.

1. Request a free trial.
2. Install Connect Bridge.
3. Handle the configuration using Connect Bridge Management Studio:
   • The API gateway authentication has two steps. To connect to SharePoint, users need to connect to Connect Bridge, and then Connect Bridge needs to connect to SharePoint.
     • Add an account for SharePoint (Accounts – Add account). You will need your SharePoint credentials.
     • Either allow the default Administrator user to use that account or create a new user and allow that user to use the SharePoint account.
   • o Click on the New Query option and then the Connection Browser. Locate the SharePoint Connector and open until you get to the DefaultConnection. Right-click on it and select Get Connection string. Then copy the appropriate connection string. You will need it for your code.

Use the New Query option to test out a query that will get the data you need from SharePoint. We will go with an example query here, still, the query should be adjusted to you what you want from SharePoint.

Once you have selected the New Query option, open the Connection Browser.

1. Find the SharePoint Connector and open until you see the Tables option. You’ll be able to see that the schema contains a “table” called Site_Pages.
2. We can use the query SELECT UniqueId, ContentType, Created, Modified, ContentVersion FROM Site_Pages LIMIT 10;
   This will select the first 10 entries from the SharePoint’s Site Pages list.

Please note that although it looks like we are using a database directly, that is not the case at all. Connect Bridge is accessing the API only and then presenting the data as if it came from a database. Feel free to explore a bit here. You can also explore the available stored procedures. Once you have your query, copy it, because you will need it on your code.

It is also important to note that, at this point, you are just testing things out. You can think of the Connect Bridge Management Studio as your playground. Once you are happy with the query you got, you simply use it in your code, as if you were accessing a database. It is quite straightforward.

For more detailed information, you can check the API gateway documentation that you will get when you receive your free trial. You can also check the API gateway logs, which in Connect Bridge is easily done by using Connect Bridge Management Studio using the option Administration Center - System - Logs on the navigation bar.

The API gateway concept might sound too theoretical at first, however, it is not hard to visualize the benefits once you focus on a specific tool like Connect Bridge.

• Access is centralized on the API gateway, independently of the number of target systems
• Not having to learn any new API or programming language can reduce errors and improve productivity
• Maintenance is also centralized and isolated - it is all on the API gateway side and not on your code, with forward compatibility guaranteed for each target system by Connect Bridge itself (and actually also backward compatibility should you ever need it)

If you have any comments or suggestions, write them in the form below and we'll respond ASAP.