github.com/hellofresh/janus@v0.0.0-20230925145208-ce8de8183c67/docs/proxy/routing_capabilities.md (about)

     1  
     2  ### Routing capabilities
     3  
     4  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:
     5  
     6  The request must include all of the configured fields
     7  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)
     8  Let's go through a few examples. Consider an API configured like this:
     9  
    10  ```json
    11  {
    12      "name": "My API",
    13      "hosts": ["example.com", "service.com"],
    14      "proxy": {
    15          "listen_path": "/foo/*",
    16          "upstreams" : {
    17              "balancing": "roundrobin",
    18              "targets": [
    19                  {"target": "http://my-api.com"}
    20              ]
    21          },
    22          "methods": ["GET"]
    23      }
    24  }
    25  ```
    26  
    27  Some of the possible requests matching this API could be:
    28  
    29  ```http
    30  GET /foo HTTP/1.1
    31  Host: example.com
    32  ```
    33  
    34  ```http
    35  GET /foo HTTP/1.1
    36  Host: service.com
    37  ```
    38  
    39  ```http
    40  GET /foo/hello/world HTTP/1.1
    41  Host: example.com
    42  ```
    43  
    44  All three of these requests satisfy all the conditions set in the API definition.
    45  
    46  However, the following requests would not match the configured conditions:
    47  
    48  ```http
    49  GET / HTTP/1.1
    50  Host: example.com
    51  ```
    52  
    53  ```http
    54  POST /bar HTTP/1.1
    55  Host: example.com
    56  ```
    57  
    58  ```http
    59  GET /foo HTTP/1.1
    60  Host: foo.com
    61  ```
    62  
    63  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.
    64  
    65  Now that we understand how the hosts, uris, and methods properties work together, let's explore each property individually.
    66  
    67  *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:
    68  
    69  ```json
    70  {
    71      "name": "My API",
    72      "hosts": ["example.com", "service.com"],
    73      "proxy": {
    74          "listen_path": "/foo/*",
    75          "upstreams" : {
    76              "balancing": "roundrobin",
    77              "targets": [
    78                  {"target": "http://my-api.com"}
    79              ]
    80          },
    81          "insecure_skip_verify": true,
    82          "methods": ["GET"]
    83      }
    84  }
    85  ```
    86  
    87  *Named url parameters:* you can have named parameters inside your upstream and then specify where they should be in the targets, like the following:
    88  
    89  ```json
    90  {
    91      "name": "My API",
    92      "proxy": {
    93          "listen_path": "/myresource/{id:[\\da-f]{24}}",
    94          "upstreams" : {
    95              "balancing": "roundrobin",
    96              "targets": [
    97                  {"target": "http://my-application.com/api/myresource/{id}"}
    98              ]
    99          },
   100          "methods": ["GET"]
   101      }
   102  }
   103  ```
   104  
   105  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.