TL;DR
L7 routing distributes API requests not just by IP address or port, but based on application characteristics. Path, hostname, HTTP method, or headers can direct to different backend pools. Clear rules, defined priorities, and a clean boundary between edge routing and internal application logic are crucial.
Introduction
A common backend pool for all API requests is easy to configure but quickly leads to unnecessary coupling. Versioned APIs, administrative endpoints, and public resources often have different scaling, security, and operational requirements. If they are indiscriminately forwarded to the same backends, the application itself must evaluate these differences.
L7 routing shifts part of this decision to the public entry point. The edge analyzes HTTP characteristics and assigns requests to appropriate services or backend pools. This creates a clear separation: the edge decides the general direction of traffic, while the application continues to manage its business logic.
1. L7 Routing Starts with an Explicit Rule Structure
A routing rule consists of three parts: a match criterion, a target, and a defined order. The match criterion describes which requests the rule applies to. Typical characteristics include hostname, URL path, HTTP method, or selected headers. The target refers to a service or a backend pool that should process the request.
The order is crucial. A general rule like /api/* should not overshadow a more specific rule for /api/v2/*. Therefore, rules should be arranged from specific to general or evaluated by a clearly defined priority. A final default rule prevents unmatched requests from being forwarded to any backend uncontrollably.
For the ayedo Edge Cloud, L7 load balancing means that HTTP and HTTPS traffic can be distributed to different targets based on such application characteristics. The specific rule structure should be documented as part of the architecture, not just as a configuration of individual teams.
2. Backend Pools Define Technical Responsibility Boundaries
A backend pool is more than a list of servers. It describes a group of backends that should process the same API traffic both functionally and operationally. A pool for /api/v1 can, for example, be served by a different deployment than a pool for /api/v2. Public and administrative endpoints can also be separated.
This separation affects scaling, release processes, and error patterns. If a pool for a new API version is scaled independently, it does not automatically influence the load of the old version. A faulty deployment remains limited to the assigned traffic, provided the routing rules do not create a common dependency.
Health checks and failover complement this structure. They check whether backends are generally reachable and operational. However, they do not replace functional error handling: a backend can return HTTP 200 and still provide incorrect data. The edge decides on availability and forwarding, not on the correctness of the API response.
3. API Routing Must Align with Versioning and Releases
L7 routing is particularly suitable for controlled transitions between API versions or deployments. A path like /v1/ can permanently point to a stable pool, while /v2/ is forwarded to a new implementation. Alternatively, headers or hostnames can be used if versions or tenants should not be visible in the path.
It is important not to confuse the routing decision with complete application logic. The edge can classify requests based on visible protocol characteristics. However, it should not take over functional authorization, complex tenant logic, or the consistency of business processes. These tasks remain within the API service.
Even with canary releases, clear boundaries are needed. A division based on a stable technical characteristic is more comprehensible than a multitude of hard-to-test special rules. If, for example, only certain headers are used for test access, clients, monitoring, and rollback processes must support this convention. Otherwise, the edge configuration itself becomes a hidden release system.
4. Handover to the Backend Defines the Operational Boundary
Between edge and application, headers, TLS, and source information must be handled unambiguously. With TLS termination at the edge, the backend must be able to recognize that the original request was received over HTTPS. For logging, access control, and diagnostics, it is also relevant which client and proxy information is passed to the application.
Proxy Protocol can supplement the connection between edge and backend with information about the original connection in suitable architectures. However, the backend must explicitly expect this protocol. An inconsistent configuration does not lead to a mere routing error but can prevent the connection establishment between edge and service.
Backend cloaking shifts public visibility entirely to the edge: clients do not need to know the internal backend addresses. This reduces the direct attack surface and prevents API clients from coupling to individual workload addresses. In the ayedo Edge Cloud, the public access is thus in front of the actual backends; the application remains responsible for the functional processing.
Practice: Two API Versions with Separate Pools
A company operates /api/v1 and /api/v2 in parallel. Both versions are accessible under the same hostname but differ in data model and scaling needs. A general forwarding to a common pool would shift version recognition to the application and complicate rollbacks.
Instead, a specific rule for /api/v2/* is evaluated before a more general rule for /api/v1/*. Both rules refer to separate backend pools. Health checks remove unreachable backends from the respective pool. A rollback of version 2 then only changes the assignment of this path, while version 1 remains unchanged. The edge controls the direction; authentication and functional validation remain in the APIs.
FAQ
What Characteristics Are Suitable for L7 Routing?
Typical criteria include hostname, URL path, HTTP method, and selected headers. It is crucial that the characteristic is stable, comprehensible for clients, and visible for operations and monitoring.
Does L7 Routing Replace an API Gateway Service?
No. L7 routing distributes requests. Functions such as functional authorization, transformations, or complex quota logic still belong in designated API or platform components.
When Is a Common Backend Pool Sufficient?
A common pool may suffice if API versions, scaling profiles, and release cycles are identical. Once these properties differ, separate assignment usually creates clearer operational boundaries.
Conclusion
L7 routing for APIs is primarily a matter of clear responsibility boundaries. Rules determine the direction, backend pools bundle similar operational requirements, and the handover defines what information a service receives. The ayedo Edge Cloud can centrally implement these decisions as a public entry point for HTTP and HTTPS services—regardless of whether the backends are operated in ayedo Managed Kubernetes, in their own cluster, or with another provider.