Getting to know the API proxy
Explore the capabilities and practical uses for an API proxy, as well as examine the relationship between an API proxy and an API gateway.
The increase in remote workers has renewed interest in API proxies, even for organizations that have a long history of exposing APIs for remote access. Remote workers require access to core applications that may not normally be exposed over the web, and the APIs associated with those applications may lack the security features necessary to protect company information.
The API proxy can help fix this problem.
The basics of an API proxy
An API proxy can be considered a subset of the API gateway pattern, a concept most developers are familiar with. These gateways are designed to manage the communication between the front end and back end of an application when those pieces are decoupled. The current catalog of gateway tools available can combine multiple APIs into a single one and translate them from one protocol to another. Other gateway features also provide load balancing, security, monitoring and auditability.
The specific role of the proxy is to connect an exposed API, sometimes referred to as the proxy endpoint, to a target API. Then, it applies policies that regulate how requests travel from the exposed API to the target API, as well as how the target will respond.
API proxy versus API gateway
On the surface, it can be hard to discern the differences between a proxy and a gateway. However, the easiest way for development teams to understand the difference is to think of proxies as simple gateways, used when only minimal processing of an inbound request is necessary.
Before choosing one or the other, developers need to audit the capabilities of the target API and create policies that enforce its usage requirements. In this audit, consider any future policies or trends that might impact the scope of the API's needs down the line. The biggest mistake you can make is to fail to consider the full requirement set.
After the audit is complete, you need to decide which better fits your needs. Generally, you'll want to consider an API proxy if its policy requirements are limited to simple procedures like access security and compliance, data model reformats or monitoring. If the API's needs go beyond this, it's better to consider a larger API gateway.
Once you've decided whether you need an API proxy or gateway, document the facts that led to the choice. In particular, document the policies attached to the target API, including policies it has failed to comply with in the past. This creates the starting point for your proxy documentation, which is critical for long-term success.
Design patterns versus API proxy
Developers can design APIs to provide support for policy management of requests, scaling and load balancing, as well as combining or reformatting of information. Design patterns, like the adapter design pattern or the storefront design pattern, can provide gateway and proxy features, rendering a separate gateway or proxy unnecessary. But these can be applied only through development. With third-party software, or when it's critical to improve or create a new API quickly, the gateway or proxy is the best approach, as long as the implementation is carefully planned.
API proxy tools
It's rarely a good idea to develop an API proxy from scratch. Instead, it's better to find a tool that can provide the framework you would otherwise need to provision yourself. Consider options from providers such as:
- Apigee
- Mashery
- Nginx
- Traefik
No matter the tool, consider the specific policies you'll need to implement. Policies are critical because it is what API proxies base their actions on. Another critical tool consideration is its capabilities for central cataloging, systematic statement, organization and documentation of policies. Never allow one proxy to store or document a certain policy differently than any other proxy, even if another development team owns that proxy.
Implementation
It's also possible that the same target API could be exposed through multiple proxies, each which may operate on different access rights or rules. Avoid this situation whenever possible, even if it means you need to implement a more complex and far-reaching API gateway. Otherwise, there is a chance that changes made to the target API might not reflect across every proxy it's paired with, which can cause major headaches surrounding mismatched management policies. However, if you do have to establish a many-to-one exposed to target relationship, take due diligence to make sure all the proxies link back to the proper target.
The final step in implementation is validation. Too often, API proxy implementations become the main focus, so it's important to validate the implementation against your original goals. This is where creating documentation that summarizes expectations for your API proxy at the beginning of your project becomes so important. That is the information you'll use to validate the performance of the proxy at the end.
Overall, the most important thing to remember about API proxies is that they're supposed to be simple. Meeting your goal doesn't so much depend on the implementation you choose, but rather on the specific APIs you target in that implementation. Picking a bad target -- such as one that requires complex policies or has feature sets that require more than simple access control and monitoring -- means you'll end up rebuilding your proxies until you ultimately must build an API gateway anyway.
