The dynamic routing policy is used to dispatch inbound calls to different targets / endpoints or to rewrite URIs.
This policy can be particularly useful when user needs to prepare a mashup of APIs into a single one.
An other typical use-case will be to define this kind of routing:
-
Requests from
http://gateway/apis/store/12/info
are redirected tohttp://backend_store12/info
-
Requests from
http://gateway/apis/store/45/info
are redirected tohttp://backend_store45/info
Name | Description |
---|---|
request.endpoint |
The endpoint URL invoked by the gateway after dynamic routing. |
When using the Dynamic Routing policy, you can define multiple rules and their respective redirections according to the initial request path.
Warning
|
When defining rule, please consider that the API’s context-path must not be part of the rule’s path!
If your context-path is /myapi and your call is /myapi/123 , if you want to select 123 the regular expression will be /(.*) .
Don’t forget the / .
|
Rules can be defined using regular expression: /v1/stores/(.*)
.
Using regular expressions can be very useful when you want to capture some parts of the initial request path and reuse them to define the redirection.
For example: the rule’s path is /v1/stores/(.*)
to capture the end of the path after /v1/stores/
and use it
in the redirect to property: http://store_backend/stores/{#group[0]}
An other great feature is the possibility to use named group instead of indexed group.
/api/(?<version>v[0-9]+)/stores.*
⇒ http://host1/products/api/{#groupName['version']}
"dynamic-routing": {
"rules": [
{
"pattern": "/v1/stores/(.*)",
"url": "http://host2/stores/{#group[0]}"
}
]
}
It’s also possible to select a configured endpoint on your API, by its name using expression language.
"dynamic-routing": {
"rules": [
{
"pattern": "/v1/stores/(.*)",
"url": "{#endpoints['default']}/{#group[0]}"
}
]
}