What is an API proxy?

An API proxy is a thin application program interface (API) server that exposes an interface for an existing service or services. A "proxy" is something that acts as an agent or intermediary for something else. In software design, proxies are often used to decouple two software components so they can evolve independently. In modern computing, and in particular with hybrid clouds, proxies are used to decouple front-end and back-end service components, the former normally deployed in the cloud and the latter in the data center.

APIs are the standard way to have software programs communicate with each other while also exposing data within different contexts and across multiple channels. APIs can also be used to connect the user interface (the "front end") with back-end services. Often, these back-end services are created by legacy applications that use interface conventions and data formats not optimal for modern front-end and cloud deployments. An API proxy is a software element that connects to back-end services, then creates a more modern and useful API to connect to the front end.

API proxies allow developers to define an API without having to change underlying services in the back end. This works by decoupling the front-end API from the back-end services, which is what shields the app from code changes on the back end. The benefit to an API proxy is that it is essentially a simple and lightweight API gateway.

API proxy vs. API gateway

An API proxy is a simple "connector" between two APIs. It provides a conversion of the API itself (message formats) and sometimes limited data conversion, but it adds no security, scalability or resilience features to the API. Whatever limitations in use that the original back-end service might have, the proxied API will also have.

API gateways are a significant enhancement to this basic model. A "gateway" in software is a component that provides access to a service, with no strict limit on what additional features or capabilities the gateway itself can provide. An API gateway, therefore, is programming that sits in front of an API and acts as a single point of entry for a defined group of back-end services. While API gateways perform the same limited functions of an "API connector," it's part of a much broader mission. API gateways can do the following:

Create a front-end API so the back-end services do not expose an API at all. For example, a gateway could mimic an existing user interface or convert a message queue into an API.
Provide access rights validation or encryption to enforce security or compliance policies.
Provide queuing services so that multiple front-end process instances can access a single back-end service.
Provide load-balancing to allow for multiple instances of back-end services and fault recovery, should a back-end service instance fail.
Convert data formats, including decoding fields and providing for data validation that might be expected by the back-end service.

Over time, industry practices have blurred the differentiation between API proxies and API gateways. Today, the "proxy" term is often used for any component that connects two APIs, generally a front-end system to a back-end service, regardless of what features may be provided, assuming the features are implemented using policies rather than custom code.

What are policies?

In an API proxy, a "policy" is a small packaged component that provides special features or capabilities that are more often (and traditionally) associated with API gateways -- without coding. These policies are attached to API proxies and are generally considered to offer "API management" features, though nearly any API-related feature could, in theory, be implemented as a policy.

There are no standards for API policies, so users of API proxies should assess the policy capabilities of any API proxy software that's under consideration before making a final decision. This is particularly true if one of the goals of the project is to minimize custom coding. API proxy software will also often support scripting or programming to create custom policies. This can be very useful when API software tools provide most of the policy capabilities needed, but leave a few implemented in a different way than the project requires, or perhaps not implemented at all.

Policy-based API proxies will usually require proxy configuration to attach policies and define "in" and "out" APIs, their structures and data formats. Since this configuration process is critical to the successful exchange of information across the API proxy, it should be treated like software development. This means that requirements gathering and documentation of every step are critical.

How to create an API proxy

It's important to be organized in approaching API proxy design and development because it's easy to make a mistake that would compromise the original mission of reducing the dependency between two components of software. The following steps should be taken to get things right -- if possible, in this order:

Inventory the APIs involved. It's rare that an API proxy or gateway would be designed without one or both associated APIs already in use. Proper API proxy creation must start by comparing the APIs and determining just what features the API proxy will have to harmonize. If the API Proxy's "back-end facing" API is already available, it's particularly important to understand whether simply adding minimal features to it will be enough to create an available, scalable implementation.
Map the workflow. An API proxy is a part of a workflow, which means that messages are expected to flow through between the front-end and back-end elements. The API proxy should be hosted to optimize that message flow, both in terms of performance and cost. If the front-end elements are highly scalable, it may be necessary to make the proxy scalable -- or to queue work on arrival -- to account for limited capacity in the back-end element.
Select a development model that fits the APIs and hosting platform. Front-end components and back-end services are often implemented in different languages, use different data structures (XML and JSON, for example) and work with different middleware tools. Try to pick a language, data structure and middleware combination that offers the easiest match between front-end and back-end development models. At this stage, identify whether policies will be needed to support the features the application requires, and if so, how complex those policies are. If the API proxy has to be scalable or resilient, be prepared to adopt stateless development principles.
Use an API proxy tool or pattern that includes the necessary policy support. If the API proxy policies need support, pick a vendor or toolkit that offers built-in support for policies at the level required. If the capabilities of a given toolkit are being pushed to its limits, then move to one with more capabilities. This will prevent having to redo the API proxy down the line if requirements change.
Apply thorough functional and load testing to the completed API proxy. Because API proxies are converters between the APIs of different components, they're very sensitive to the specific interfaces of each. Every variation on data structures and parameter combinations need to be tested, and a realistic load test is essential to ensure that the API proxy doesn't interfere with the user experience.
Add the API proxy to the dependency list for both front-end and back-end APIs. A change to either API could render an API proxy nonfunctional, or worse, create data or parameter problems that make the operation of one or both components incorrect.