API Proxy Client Route Usage Guide

Overview
Apinizer's Client Route feature enables more flexible and dynamic routing of incoming requests in the API Gateway. With this feature:
- Multiple relative paths can be defined for a proxy
- Routing can be done to different proxies based on host information
- Routing rules can be created based on HTTP header values
- Method-based routing can be performed
Before this feature was developed, only a single unique relative path could be defined for each proxy. With the new feature, multiple proxies with the same relative path can be created, and dynamic routing can be performed between them based on host, header, or method information.
How Does Client Route Work?
The Client Route feature evaluates incoming requests according to a specific priority order and routes them to the correct proxy.
Routing Priority Order
The Gateway evaluates incoming requests according to the following priority order:
- Relative Path (Highest priority)
- Hosts
- Headers
- Methods (Lowest priority)
Matching Logic
- Hosts: When multiple hosts are defined, it works with OR logic. That is, matching any one of the defined hosts is sufficient.
- Headers: When multiple headers are defined, it works with AND logic. That is, all defined headers must match.
Wildcard Hostname Usage
Apinizer supports wildcard (joker character) usage to provide flexibility in host definitions. Wildcard hostnames allow all Host header values that match a certain pattern to satisfy the condition and thus match the related Route.
Wildcard Rules
Wildcard hostnames must comply with the following rules:
- Can contain only one asterisk (*) in the leftmost or rightmost label of the domain
- Asterisk can be used at the beginning or end of the domain
Wildcard Examples
Left-Side Wildcard
*.example.com
This definition enables matching of the following Host values:
- a.example.com
- x.y.example.com
- api.example.com
- test.subdomain.example.com
Right-Side Wildcard
example.*
This definition enables matching of the following Host values:
- example.com
- example.org
- example.net
- example.io
## Example Scenario
The table below shows 5 different proxies and the Client Route configurations defined for them.
| Proxy ID | Relative Path | Methods | Hosts (OR) | Headers (AND) |
| -------- | ------------------- | ------- | -------------------------------- | ------------------------ |
| 1 | /jokes | \- | \- | testmode:true, test:true |
| 2 | /jokes | \- | hostname\_x.com, hostname\_y.com | \- |
| 3 | /jokes1/endpoint\_x | \- | \- | \- |
| 4 | /jokes1 | \- | \- | \- |
| 5 | /jokes | \- | \- | \- |
### Routing Examples
According to this configuration, incoming requests are routed as follows:
#### Example 1: Basic Routing
**Request:**
```text
GET https://<ACCESS_URL>/jokes
Result: Routed to Proxy 5 (default proxy since no condition is met)
Example 2: Host-Based Routing
Request:
GET https://<ACCESS_URL>/jokes
Host: hostname_x.com
Result: Routed to Proxy 2 (host condition met)
Example 3: Routing with Missing Header
Request:
GET https://<ACCESS_URL>/jokes
testmode: true
Result: Routed to Proxy 5 (Proxy 1 requires both headers, only one is provided)
Example 4: Full Header Match
Request:
GET https://<ACCESS_URL>/jokes
testmode: true
test: true
Result: Routed to Proxy 1 (all header conditions met)
Example 5: Path Priority - Basic Path
Request:
GET https://<ACCESS_URL>/jokes1
Result: Routed to Proxy 4 (exact path match)