API proxy

An API proxy sits between client applications and the backend APIs they call, whether those APIs are in-house, private or public. It gives you a single, controlled point through which API traffic flows, so you can add caching, observability and resilience without changing the calling application.

HARP implements this topology as a forward proxy: you run it close to your application, it maps a local listening port to a remote backend, and your code calls the proxy instead of the API directly.

What an API proxy does

An API proxy is an intermediary layer in front of one or more backend APIs. It receives requests from the client, applies cross-cutting logic such as caching, request and response manipulation, and failure handling, then forwards the request to the appropriate backend. The client keeps talking to a stable endpoint while the proxy absorbs the messy details of the upstream APIs.

Because it runs at the closest possible network proximity to your application, ideally on the same server or within the same virtual network, the overhead it adds to each call stays negligible.

API proxy compared to an API gateway

API proxies and API gateways are related but solve different problems.

• An API proxy is typically a forward proxy for outgoing traffic towards the backend services your application consumes. It focuses on caching, observability and resilience for the APIs you depend on.
• An API gateway is typically a reverse proxy for incoming traffic, sitting in front of the APIs you expose. It acts as a central entry point, aggregates services, translates between protocols and distributes incoming load across them.

A proxy can take on some gateway-style tasks, but a dedicated gateway is the better fit when you need to publish and orchestrate many of your own APIs. The right choice depends on whether you are protecting the APIs you consume (proxy) or the APIs you serve (gateway).

Why HARP fits the API proxy role

HARP is an open-source, self-hosted HTTP API Runtime Proxy written in Python using asyncio, httpx and Hishel. It provides proxy capabilities at runtime, without changing your application code:

• Caching: a RFC-9111 compliant HTTP cache layer that reduces redundant calls and improves response times for the APIs you consume.
• Resilience: circuit breaking with configurable failure and success thresholds, periodic liveness probes to reattempt failed remotes, and active and fallback remote pools for automatic failover.
• Basic load balancing: requests are spread across the remotes kept in an endpoint's active pool.
• Request and response manipulation: a Python rules engine to adjust traffic as it passes through.
• Observability: a built-in dashboard, an audit log, Prometheus metrics, and a /healthz endpoint for liveness and readiness checks.

Configuration is declarative: you describe endpoints, their listening ports and their remotes in YAML, and HARP handles the rest. A command-line form is also available for quick testing.