How to Configure Routes using Expressions

Edit to contain the line and restart Kong Gateway. Note: once you enable expressions, the match fields that traditionally exist on the Route object (such as paths, methods) will no longer be configurable and you must specify Expressions in the expression field.

To create a new router object using expressions, send a POST request to the like this:

In this example, you associated a new route object with the path /mock to the existing service example-service. The Expressions DSL also allows you to create complex router match conditions.

curl --request POST \
  --url http://localhost:8001/services/example-service/routes \
  --form 'expression=(http.path == "/mock" || net.protocol == "https")'

In this example the || operator created an expression that set variables for the following fields:

curl --request POST \
  --url http://localhost:8001/services/example-service/routes \
  --form 'expression=http.path == "/mock" && (net.protocol == "http" || net.protocol == "https")'

You can describe complex route objects using operators within a POST request.

curl --request POST \
  --url http://localhost:8001/services/example-service/routes \
  --header 'Content-Type: multipart/form-data' \
  --form name=complex_object \
  --form 'expression=(net.protocol == "http" || net.protocol == "https") &&
         (http.method == "GET" || http.method == "POST") &&
         (http.path ^= "/mock" || http.path ^= "/mocking") &&
         http.headers.x_another_header == "example_header" && (http.headers.x_my_header == "example" || http.headers.x_my_header == "example2")'

For a list of all available operators, see the .

The Expressions router stops evaluating the remaining rules as soon as the first match is found.

For example, given the following config:

The evaluation order will be: Route 1 then Route 2 and finally Route 3.

Generally, Expressions are evaluated sequentially until a match could be found. This means with large number of Routes, the worst case match time will tends to scale linearly as the number of routes increase. Therefore it is desirable to reduce the number of unique routes by leveraging the combination capability of the language.

Keep regex usages to a minimum. Regular expressions are much more expensive to build and execute, and can not be optimized easily. Leveraging the powerful operators provided by the language instead.

Exact matches

When performing exact (not prefix) matches on paths, traditionally regex has to be used in the following form:

paths: ["~/foo/bar$"]

http.path == "/foo/bar"

Optional slash at the end

Sometimes it is desirable to match both /foo and /foo/ in the same route. Traditionally, this has been done using the following regex:

paths: ["~/foo/?$"]

With Expressions, avoid using regex by write the following:

Multiple routes with same Service and Plugin config

If multiple routes results in the same Service and Plugin config being used, they should be combined into a single Expression Route with logical or operator ||.

Example:

Route 1:

service: example-service
expression: http.path == "/hello"

Route 2:

service: example-service
expression: http.path == "/world"

expression: http.path == "/hello" || http.path == "/world"

This reduces the number of routes the Expressions engine has to consider, which helps with the matching performance at runtime