Routing capabilities

Let's now discuss how Janus matches a request to the configured hosts, uris and methods properties (or fields) of your API. Note that all three of these fields are optional, but at least one of them must be specified. For a client request to match an API:

The request must include all of the configured fields The values of the fields in the request must match at least one of the configured values (While the field configurations accepts one or more values, a request needs only one of the values to be considered a match) Let's go through a few examples. Consider an API configured like this:

{
    "name": "My API",
    "hosts": ["example.com", "service.com"],
    "proxy": {
        "listen_path": "/foo/*",
        "upstreams" : {
            "balancing": "roundrobin",
            "targets": [
                {"target": "http://my-api.com"}
            ]
        },
        "methods": ["GET"]
    }
}

Some of the possible requests matching this API could be:

GET /foo HTTP/1.1
Host: example.com

GET /foo HTTP/1.1
Host: service.com

GET /foo/hello/world HTTP/1.1
Host: example.com

All three of these requests satisfy all the conditions set in the API definition.

However, the following requests would not match the configured conditions:

GET / HTTP/1.1
Host: example.com

POST /bar HTTP/1.1
Host: example.com

GET /foo HTTP/1.1
Host: foo.com

All three of these requests satisfy only two of configured conditions. The first request's URI is not a match for any of the configured uris, same for the second request's HTTP method, and the third request's Host header.

Now that we understand how the hosts, uris, and methods properties work together, let's explore each property individually.

Insecure upstream: if your upstream uses a self-signed SSL certificate, you can let Janus accept it, by using the insecure_skip_verify configuration, like the following:

{
    "name": "My API",
    "hosts": ["example.com", "service.com"],
    "proxy": {
        "listen_path": "/foo/*",
        "upstreams" : {
            "balancing": "roundrobin",
            "targets": [
                {"target": "http://my-api.com"}
            ]
        },
        "insecure_skip_verify": true,
        "methods": ["GET"]
    }
}

Named url parameters: you can have named parameters inside your upstream and then specify where they should be in the targets, like the following:

{
    "name": "My API",
    "proxy": {
        "listen_path": "/myresource/{id:[\\da-f]{24}}",
        "upstreams" : {
            "balancing": "roundrobin",
            "targets": [
                {"target": "http://my-application.com/api/myresource/{id}"}
            ]
        },
        "methods": ["GET"]
    }
}

When you define a parameter in the upstream you can provide regex to match a pattern, then when you define the target you can put the parameter anywhere you like.