How to Configure Routes using Expressions

Expressions can describe routes or paths as patterns using logical expressions. This how-to guide will walk through switching to the new router, and configuring routes with the new expressive domain specific language. For a list of all available operators and configurable fields please review the reference documentation.

Prerequisite

Edit kong.conf to contain the line router_flavor = expressions 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.

Create routes with Expressions

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

  1. curl --request POST \
  2.   --url http://localhost:8001/services/example-service/routes \
  3.   --form-string expression='http.path == "/mock"'

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.

  1. curl --request POST \
  2.   --url http://localhost:8001/services/example-service/routes \
  3.   --header 'Content-Type: multipart/form-data' \
  4.   --form-string 'expression=(http.path == "/mock" || net.protocol == "https")'

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

  1. curl --request POST \
  2.   --url http://localhost:8001/services/example-service/routes \
  3.   --header 'Content-Type: multipart/form-data' \
  4.   --form-string 'expression=http.path == "/mock" && (net.protocol == "http" || net.protocol == "https")'

Create complex routes with Expressions

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

  2. curl --request POST \
  3.   --url http://localhost:8001/services/example-service/routes \
  4.   --header 'Content-Type: multipart/form-data' \
  5.   --form-string name=complex_object \
  6.   --form-string 'expression=(net.protocol == "http" || net.protocol == "https") &&
  7.                 (http.method == "GET" || http.method == "POST") &&
  8.                 (http.host == "example.com" || http.host == "example.test") &&
  9.                 (http.path ^= "/mock" || http.path ^= "/mocking") &&
  10.                 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 reference documentation.

Matching priority

When the Expressions router is used, available expressions are evaluated using the priority field of the corresponding Route object where the expression is configured. Routes are evaluated in order of priority, where the highest priority integer is evaluated first. If two routes have the same priority, then the route with the higher id (UUID) will be evaluated first as a tie-breaker.

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

For example, given the following config:

  1. Route 1 =>
  2. id: 82c8e89f-ddff-42f0-a1b8-4d1120547624
  3. priority: 100,
  4. expression: ...
  6. Route 2 =>
  7. id: 72c8e89f-ddff-42f0-a1b8-4d1120547624
  8. priority: 100,
  9. expression: ...
  11. Route 3 =>
  12. id: 92c8e89f-ddff-42f0-a1b8-4d1120547624
  13. priority: 99,
  14. expression: ...

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

Performance considerations when using Expressions

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.

Examples

Exact matches

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

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

Routers with large amount of regexes are expensive to build and execute. With Expressions, avoid using regex by write the following:

  1. 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:

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

With Expressions, avoid using regex by write the following:

  1. http.path == "/foo/bar" || http.path == "/foo/bar/"

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:

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

Route 2:

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

Should be combined as:

  1. service: example-service
  2. 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

More information