API Proxy vs API Gateway

Although Application Programming Interface (API) proxies and API gateways have somewhat similar high-level goals, the two are significantly different in both functionality and capabilities. APIs and microservices transformed the way businesses built their applications and interact with consumers. However, a setup which exposes multiple IP addresses has inherent weaknesses as this presents multiple targets for bad actors. API gateways could mitigate the risks associated with the API and microservice architecture. A robust API gateway should be capable of the main functions of an API proxy; these will be explored in this article in detail. However, there are key differences to highlight between API proxies and gateways.

1. What is a Proxy
2. Rate Limiting and Quotas
3. API Gateway as a Reverse Proxy
4. Selecting Between a Proxy and a Gateway

What is a Proxy?

A proxy server behaves like an intermediary between nodes behind the proxy, in this case, microservices and APIs, and the wider internet. In the case of an API proxy, the microservices of an application will only communicate with the API proxy. The role of an API proxy is to then communicate with customers querying the application. There are several features of a proxy which can be used to protect microservices, including the proxy’s ability to encrypt the data sent by the microservices. By isolating the APIs from direct contact with the wider internet, the IP addresses of the microservices are hidden. Further, proxies are tools which can be used to control the internet usage and bandwidth of the nodes lying behind the proxy, thus an important feature of API proxies: rate-limiting and quotas.

Rate-Limiting and Quotas

An API gateway, like an API proxy, can be used to enforce rate limits and quotas. Rate-limiting refers to the restriction of the frequency which consumers can query an API or accessing a microservice. Among the various reasons to implement such a policy is to prevent accidental and incidental distributed denial of service (DDOS). If genuine consumers repeatedly request a resource in a short space of time, it could result in resource starvation for other consumers. Additionally, there are certain transactions which should have a minimum period before another is authorized. Latency, particularly during a high -volume period on a transaction executed on a mobile application, could result in a consumer assuming the request timed-out and they may be tempted to repeat the request due to impatience. If the consumer successfully repeats the transaction, there may be unintended consequences. An example would be repeating a PayPal transaction and double-paying for goods or services.

There are several strategies to implement rate-limiting, including spike-arrests, which limit sudden spikes, and quotas – which limit the number of overall queries in a predefined period. These same strategies are also used to implement service level agreements (SLAs) – which are tiers of access levels assigned to authenticated users. Essentially, this means, as an API gateway, an API proxy can be used to control the flow of traffic and access to specific microservices behind the proxy. Additionally, API proxies can provide transport layer security (TLS) which inspects incoming connections to prevent malicious actors attempting to initiate a distributed denial of service (DDoS) attacks. These functions essentially fall under security, performance management, authorization, and authorization. However, API gateways are more robust in executing these functions. API gateways, for example, can validate incoming data and utilise OpenID, OAuth 2.0 or other methods to authenticate users, which are more advanced security features They also perform traffic routing, throttling, orchestration and load balancing, which are enhanced performance monitoring and authorization features.

Authentication and authorization are an important feature for any successful application or system. However, it has to be noted that the most secure practices with regards to maintaining the integrity of the authentication and authorization protocols are often viewed as inconvenient for users. Take the two-step authentication process, for example. If users were required to input a combination of username & password as well as a one-time pin with each transaction, for example, the repetitive process would annoy even the most fervent of customers. This is why applications need to be on a platform which integrates various methods of authentication depending on the level of security required. Beyond their rate-limiting, logging and reporting security features, platforms like DreamFactory support a range of authentication options, including the standard username & password, the convenient one-click OAuth log-ins such as Facebook, Google and LinkedIn and the more robust Active Directory over Lightweight Directory Access Protocol (AD/LDAP). Further, there are multiple authorization options and choosing the right ones depends on the role of your users and the nature of their organization. For example, an application used by developers would likely use API keys, whereas a multi-level, multi-role organization would require Role-Based or Record-Level Access Control – all of which are supported by DreamFactory.

API Gateway as a Reverse Proxy

As previously mentioned proxy can control internet usage and bandwidth. This means that the proxy can determine which sites on the wider internet can be accessed by the nodes protected by the proxy, and the bandwidth which a node can access. An API gateway, on the other hand, can restrict the microservices which external consumers can access within the protected architecture as well as control the bandwidth which flows into the system. As such, an API gateway behaves like a reverse proxy while protecting the internal systems of an application. It is vital to note that API proxies and API gateways are not substitutes of each other. Although they provide comparable functionality and the latter is more comprehensive than the former, there are situations where proxies are sufficient for an organization, just as there are systems which require at least a gateway and instances when it is appropriate to use both.

API Proxy versus API Gateway

Deciding between API Proxies and API Gateways depends on what kind of capabilities you require as well as how far along you are in the API lifecycle. If the API is advanced enough, you can use an API Proxy for a quick solution that is cost effective but scrappy. Ideally, an API Proxy is a Band-Aid solution and will hold you over until a younger API is created, but shouldn’t be used alone for long term projects. Complex APIs and APIs that are valuable might need a Gateway with additional proxies as an additional feature, no matter where they are in the API lifecycle in order to deal with layers of development and resources. We discuss this further below.

Selecting Between a Proxy and Gateway

Surprisingly, there are alleged drawbacks of having an API gateway over an API proxy including latency and connection issues, complexity in setting up and maintenance, and overall costs of running the tool. Granted that an API proxy is akin to a simpler, lightweight security measure compared to the API gateway, robust API gateways can be scaled up and down with regards to complexity and functionality.

The best platforms allow the seamless integration of specific functionality and can be hosted either on-premise or in the cloud while remaining affordable to set up and manage. As such, the question should not be about choosing between an API gateway and a proxy, rather about choosing the correct platform to run a gateway and deciding if a proxy should be an additional feature.

Terence Bennett

Terence Bennett, CEO of DreamFactory, has a wealth of experience in government IT systems and Google Cloud. His impressive background includes being a former U.S. Navy Intelligence Officer and a former member of Google’s Red Team. Prior to becoming CEO, he served as COO at DreamFactory Software.