dynamic-routing.md

description
This page provides the technical details of the Dynamic Routing policy

Dynamic Routing

Overview

The dynamic-routing policy is used to dispatch inbound calls to different targets and endpoints or to rewrite URIs. This policy is particularly useful for creating API mashups.

Another typical use case is defining routing similar to the following:

• Requests from http://gateway/apis/store/12/info are redirected to http://backend_store12/info
• Requests from http://gateway/apis/store/45/info are redirected to http://backend_store45/info

Functional and implementation information for the dynamic-routing policy is organized into the following sections:

• Examples
• Configuration
• Compatibility Matrix
• Errors
• Changelogs

Examples

{% hint style="warning" %} This policy can be applied to v2 APIs and v4 HTTP proxy APIs. It cannot be applied to v4 message APIs or v4 TCP proxy APIs. {% endhint %}

{% tabs %} {% tab title="HTTP proxy API example" %} Sample policy configuration:

"dynamic-routing": {
    "rules": [
        {
            "pattern": "/v1/stores/(.*)",
            "url": "http://host2/stores/{#group[0]}"
        }
    ]
}

You can also select endpoints configured for your API by name using Gravitee Expression Language:

"dynamic-routing": {
    "rules": [
        {
            "pattern": "/v1/stores/(.*)",
            "url": "{#endpoints['default']}/{#group[0]}"
        }
    ]
}

{% endtab %} {% endtabs %}

Configuration

You can configure multiple rules and their respective redirections relative to the initial request path. When you define rules, it is important to remember that the API context-path must not be part of the rule’s path.

For example, if your context-path is /myapi and your call is /myapi/123, if you want to select 123, the regular expression is /(.*) (don’t forget the /).

Regular expressions

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, to capture the end of a path after /v1/stores/, the rule path is /v1/stores/(.*). You can then use it in the redirect to property: http://store_backend/stores/{#group[0]}

You can also use named groups instead of indexed groups: /api/(?<version>v[0-9]+)/stores.* ⇒ http://host1/products/api/{#groupName'version'}

Phases

The phases checked below are supported by the dynamic-routing policy:

v2 Phases	Compatible?	v4 Phases	Compatible?
onRequest	true	onRequest	true
onResponse	false	onResponse	false
onRequestContent	false	onMessageRequest	false
onResponseContent	false	onMessageResponse	false

Attributes

The dynamic-routing policy can be configured with the following attributes:

Name	Description
request.endpoint	The endpoint URL invoked by the gateway after dynamic routing

Compatibility matrix

The following is the compatibility matrix for APIM and the dynamic-routing policy:

Plugin Version	Supported APIM versions
Up to 1.x	All

Errors

Phase	HTTP status code	Message
onRequest	400	When no rules match the inbound request

Changelogs

{% @github-files/github-code-block url="https://github.com/gravitee-io/gravitee-policy-dynamic-routing/blob/master/CHANGELOG.md" %}