When Cloud-native API Gateway processes an incoming request, it evaluates the configured route rules in descending order of priority. If a request matches a rule, the gateway forwards it to the backend service defined in that rule. If no rule matches, the gateway returns a 404 error.
Route matching priority
The prioritization rules are as follows: Associated Domain Name > Path > Header > Query Parameters > Created At.
-
Based on the Associated Domain Name: The longer the domain string, the higher the priority.
-
Based on the Path:
-
For different Match Rule types, the priority is: Equals To > Prefix > Regular Expression Match.
-
For the same Match Rule type, a longer Path string has higher priority.
-
-
Based on the total number of key-value pairs in the Header: The more pairs, the higher the priority.
-
Based on the total number of key-value pairs in the Query Parameters: The more pairs, the higher the priority.
-
Based on the Created At: The earlier the creation time, the higher the priority.
Route rules of all APIs in the same instance are sorted together during matching and are evaluated based on the preceding priorities. Routes that belong to different APIs follow the same rules as long as they do not conflict.
When a REST API is published as a prefix route, the gateway does not generate one route per API operation. The whole API is collapsed into one prefix route that matches requests by the effective base path of the API, so that route takes part in the priority rules above as a prefix-match route: a longer matched path string has higher priority, and an exact match takes precedence over a prefix match, which in turn takes precedence over a regular expression match.
When routes generated by REST APIs, HTTP APIs, and WebSocket APIs coexist under the same gateway and domain name, the gateway matches ordinary REST API routes first, then HTTP API and WebSocket API routes, and finally REST APIs that are published as prefix routes. If the matching scope of an HTTP API or WebSocket API route overlaps that of a REST API published as a prefix route, a fully matched HTTP API or WebSocket API route takes precedence.
Procedure
-
Cloud-native API Gateway provides two ways to create routes: from outside an instance or from within an instance.
Outside instance
-
Log on to the Cloud-native API Gateway console. In the navigation pane on the left, choose API. In the top menu bar, select a region.
-
Click the target API. In the drop-down list that appears, select the instance where the route will be configured, or select All Instances. From the All Instances drop-down menu at the top, select the target instance.
-
Click Create Route.
Inside instance
-
Log on to the Cloud-native API Gateway console. In the navigation pane on the left, choose Instance. In the top menu bar, select a region.
-
On the Instance page, click the ID of the target gateway instance. In the navigation pane on the left, choose API, and then click the target API.
-
Click Create Route.
-
-
On the Create Route page, configure the parameters, and then click Save or Save and Publish.
Note-
Match rules are combined using a logical AND. The more rules you specify, the narrower the matching scope.
-
The matching priority of routes corresponds to their display order on the route configuration page.
Parameter
Description
Route Name
Enter a custom name for the route.
Route Description
Click Add Route Description to enter a description for the route.
Domain Name
-
Select one or more domains for the route to match.
-
To create a new domain, click Add Domain and create it in the panel that appears.
Path
Specifies the path parameter in the HTTP request to match.
-
For the same match rule type, a longer path string has higher priority.
-
For different match rule types, the priority is: Equals To > Prefix > Regular Expression Match.
-
Equals To: The request path must be an exact match. For example, it must be exactly
/user. -
Prefix: The request path must start with the specified prefix, for example,
/user. -
Regular Expression Match: The request path must match the specified regular expression.
-
Method
Specifies the method parameter in the HTTP request to match. You can select multiple HTTP methods. The default is ANY.
Header
Specifies the header parameters in the HTTP request to match. For the same match rule type, a rule with more parameters has higher priority.
Query Parameters
Specifies the query parameters in the HTTP request to match. For the same match rule type, a rule with more parameters has higher priority.
Instance
Select the Cloud-native API Gateway instance where the route will take effect.
Scenario
Select the target service type for the current route.
-
Basic: Single Service
-
Grayscale release: By Percentage (Multi-service), Tag (Tag-based Routing)
-
Other: Mock, Redirect
For more information about different types of target services, see Routes.
NoteThe sum of traffic weights for all weighted target services must be 100%.
Backend Services
Select an associated backend service and port.
Note-
You can click Associated Service to select a source and service in the panel.
-
Different source types have different limits on the number of sources you can add.
-
You can add a maximum of five sources for Container Service for Kubernetes (ACK).
-
You can add only one Nacos or Zookeeper source.
-
Timeout Period (seconds)
Enter the timeout duration. The default is 60 seconds. A value of 0 indicates no timeout.
Fallback
Specify a fallback service. If the backend service for a route has no available nodes, the gateway routes the original request to the specified fallback service.
NoteCurrently, the fallback feature is supported only between HTTP services.
Retry Times
Enter the number of retries. The default is 2. A value of 0 disables retries.
Retry Condition
Select the conditions that trigger a retry.
Retry Status Code
Add one or more status codes that trigger a retry.
-