Skip to main content
Client Route is the configuration settings that determine how incoming requests to your API Proxies will be routed. For detailed information about the Client Route concept, you can refer to the Client Route page.

Client Route Features

Overview: Image 2024 9 9 15 35 35 Pn With the Client Route feature, you can use the following routing options:

Multiple Paths

You can define multiple relative paths for an API Proxy

Host-Based Routing

You can route to different API Proxies based on host information

Header-Based Routing

You can create routing rules based on HTTP header values

Method-Based Routing

You can perform HTTP method-based routing
Before this feature was developed, only a single unique relative path could be defined for each API Proxy. With the new feature, multiple API Proxies with the same relative path can be created, and dynamic routing can be performed between them based on host, header, or method information.

Routing Priority Order

The Gateway evaluates incoming requests according to the following priority order:

1. Relative Path

Highest priority

2. Hosts

Host header check

3. Headers

Header check

4. Methods

Lowest priority

Matching Logic

Hosts (OR Logic)

When multiple hosts are defined, it works with OR logic. That is, matching any one of the defined hosts is sufficient. Example:
If the Host header value in the request is hostname_x.com or hostname_y.com, the condition is met.

Headers (AND Logic)

When multiple headers are defined, it works with AND logic. That is, all defined headers must match. Example:
Both testmode: true and test: true headers must be present in the request.

Path Matching

  • Relative path matching has the highest priority
  • More specific (longer) paths are evaluated before more general (shorter) paths
  • If an exact match is not found, the closest parent path is used

Method Matching

  • Method checking has the lowest priority
  • If not specified, all HTTP methods are accepted

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 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

Matching Hosts:
  • a.example.com
  • x.y.example.com
  • api.example.com
  • test.subdomain.example.com

Right-Side Wildcard

Matching Hosts:
  • example.com
  • example.org
  • example.net
  • example.io

Example Scenario

The table below shows 5 different API Proxies and the Client Route configurations defined for them:

Routing Examples

According to this configuration, incoming requests are routed as follows:
Request:
Result: Routed to Proxy 5 (default proxy since no condition is met)
Path matched but host and header conditions were not met, so Proxy 5 with the simplest configuration is selected.
Request:
Result: Routed to Proxy 2 (host condition met)
Proxy 2 is selected because host has higher priority than header.
Request:
Result: Routed to Proxy 5 (Proxy 1 requires both headers, only one is provided)
Since headers work with AND logic, all headers must match. In case of missing headers, the next suitable proxy is selected.
Request:
Result: Routed to Proxy 1 (all header conditions met)
Proxy 1 is selected because all header conditions are met.
Request:
Result: Routed to Proxy 4 (exact path match)
Proxy 4 is selected because path has the highest priority and it has an exact matching path.
Request:
Result: Routed to Proxy 3 (more specific path takes priority)
More specific (longer) paths are evaluated before more general (shorter) paths.
Request:
Result: Routed to Proxy 3 (closest parent path match)
If an exact match is not found, the closest parent path is used.
Request:
Result: Routed to Proxy 4 (matched /jokes1 as parent path)
There is no exact match for /jokes1/endpoint_y path, so the parent path match /jokes1 is used.
Request:
Result: Routed to Proxy 2 (host has higher priority than header)
Proxy 2 is selected because host has higher priority than header, so when host condition is met, header conditions are ignored.
Request:
Result: Routed to Proxy 4 (path has highest priority, host and headers are ignored)
Proxy 4 is selected because path has the highest priority, so when path match is met, host and header conditions are ignored.

Routing Combination Table

This table shows from the API Proxy perspective how the API Proxy is selected: The table below shows how the API Proxy is selected in different combinations:

Important Notes

  • Relative path matching has the highest priority
  • More specific (longer) paths are evaluated before more general (shorter) paths
  • If an exact match is not found, the closest parent path is used
  • Multiple hosts can be defined
  • Hosts work with OR logic
  • If the host value in the request matches any of the defined hosts, the condition is met
  • Multiple headers can be defined
  • Headers work with AND logic
  • All headers defined in the request must be present
  • In case of missing or incorrect headers, it moves to the next suitable proxy
  • Method checking has the lowest priority
  • If not specified, all HTTP methods are accepted
The Client Route feature allows you to easily manage complex routing scenarios in your API Gateway. By understanding the priority order and matching logic correctly, you can create flexible and powerful API routing configurations.

Client Route

Learn about Client Route concept

API Proxy Creation

API Proxy creation

Routing and Upstream

Learn about Routing and Upstream concepts

HTTP Routing

HTTP Routing configuration

API Proxy Configuration

API Proxy settings