Concretely, what request attributes can a routing gateway use to pick a backend, and what's a practical difference between routing by URL path versus routing by a request header?

## The signals a gateway can match on A routing gateway needs some deterministic signal in each incoming request to decide which backend should handle it, and in practice that signal comes from a small set of well-understood request attributes. 1. **URL path.** The most common is the URL path: a rule like `/api/orders/**` captures everything under that prefix and forwards it to the order service, while `/api/catalog/**` goes elsewhere. Path-based routing is popular because it is visible and self-documenting: anyone reading a URL, a log line, or an API doc immediately sees which resource family they are calling, and CDNs, browsers, and proxies can cache and route on it trivially since it requires no special parsing beyond the URL itself. 2. **Host header or subdomain.** A second matcher is the Host header or subdomain: `orders.example.com` and `catalog.example.com` can be routed to different backends even though they share a gateway's IP and TLS certificate handling (via SNI), which is common when different services are meant to look like fully separate products or when a platform hosts many tenants each on their own subdomain. 3. **Custom request header.** A third matcher is a custom request header, such as `X-API-Version: 2` or `X-Canary: true`. Headers are invisible in the URL, which is precisely their value: they let the gateway make a routing decision based on something the client doesn't have to encode into every link or bookmark, such as which version of the API contract a particular client integration understands, or whether this particular request should be diverted into a canary release. 4. **Query parameter.** A fourth, less common matcher is a query parameter (`?version=2`), which behaves like a lightweight header but is visible in the URL and therefore gets logged, cached, and bookmarked, which is often undesirable for anything that changes frequently like a canary flag. ## Path versus header The practical difference between path-based and header-based routing comes down to visibility, coupling, and failure behavior. - **Path-based rules are simple to reason about**, because the routing decision is baked into the URL the client explicitly constructed; there's no ambiguity about what a client 'meant' to call, and the rule can be tested by simply hitting the URL. The cost is that the resource boundary becomes part of the client-visible contract: if you later want to route the same logical resource to different backends based on some other axis (say, which API version a client speaks), you either have to change the URL scheme (which is itself a versioning decision with its own costs) or add another matcher on top. - **Header-based rules decouple the routing axis from the resource path**, so the same URL can be served by different backends for different callers without any URL churn. That flexibility comes with an operational cost: it depends entirely on the header surviving the full path from client to gateway. ## The failure behavior header routing brings Any intermediate proxy, CDN, or client library that strips 'unrecognized' headers by default silently reverts the request to whatever the gateway's default rule is, and because the URL looks completely normal, this failure is invisible unless you're specifically monitoring which backend actually served each request. It also means the routing behavior is undiscoverable from the URL alone: you cannot tell what a request will do just by reading it, you have to know which headers matter, which makes debugging and reproducing issues (e.g. in a browser address bar) harder than with path-based rules. ## How teams combine the two In production, teams typically combine both: path-based routing to split large resource domains into services (the coarse, stable structural decision), and header-based routing layered within a given path for finer-grained, more volatile concerns like API versioning or canary membership, where you don't want a URL-scheme change every time you roll out a new version. AWS API Gateway and Azure Application Gateway both support path- and header-based listener rules natively; Kubernetes Ingress historically leaned path/host-based, while service meshes like Istio's VirtualService resources support header-based routing explicitly for exactly the canary and version-negotiation use cases described above. ## A concrete scenario A concrete real scenario: a mobile app that cannot be force-updated sends `X-API-Version: 1`, while a freshly released web client sends `X-API-Version: 2`; the gateway routes both to the same `/api/orders` path but to two different backend deployments, letting the backend team retire the v1 handler only once telemetry shows v1 traffic has dropped to zero, all without ever changing the URL either client calls.