Service management
In a large organization, applications call many internal and external APIs, and no single place shows which remote services are in use or how they behave. HARP sits between your applications and the APIs they call, so every outbound dependency becomes a named endpoint that is declared, observed, and operated from one place, without changing application code.
Understanding the use case
When teams call APIs directly, there is no shared inventory of which services are in use, traffic is hard to observe, and each client configures retries and caching its own way, so behaviour drifts between services. Because HARP routes that traffic through named endpoints, you get one explicit list of dependencies, one dashboard view of how each behaves, and one place to apply consistent handling.
How HARP helps
-
A single inventory: declare each remote API as a named endpoint in HARP. That endpoint becomes both the address your applications call and the explicit list of the services they depend on.
-
Observable traffic: the HARP dashboard shows the transactions flowing through each endpoint, alongside system and performance state, so problems are visible instead of buried in client code.
-
Consistent behaviour: configure caching, the circuit breaker, and request and response handling once in HARP rather than reimplementing them per team. The rules engine can also rewrite traffic in transit, for example injecting an authorization header or stripping one before a call leaves your perimeter.
-
Kubernetes-native: the HARP Helm chart creates an internal ClusterIP service for each configured endpoint, so applications target a stable in-cluster name without extra service-discovery wiring.