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

     1  #### Request URI
     2  
     3  Another way for Janus to route a request to a given upstream service is to
     4  specify a request URI via the `proxy.listen_path` property. To satisfy this field's
     5  condition, a client request's URI **must** be prefixed with one of the values
     6  of the `proxy.listen_path` field.
     7  
     8  For example, in an API configured like this:
     9  
    10  ```json
    11  {
    12      "name": "My API",
    13      "proxy": {
    14          "listen_path": "/hello/*",
    15          "upstreams" : {
    16              "balancing": "roundrobin",
    17              "targets": [
    18                  {"target": "http://my-api.com"}
    19              ]
    20          },
    21          "methods": ["GET"],
    22      }
    23  }
    24  ```
    25  
    26  The following requests would match the configured API:
    27  
    28  ```http
    29  GET /hello HTTP/1.1
    30  Host: my-api.com
    31  ```
    32  
    33  ```http
    34  GET /hello/resource?param=value HTTP/1.1
    35  Host: my-api.com
    36  ```
    37  
    38  ```http
    39  GET /hello/world/resource HTTP/1.1
    40  Host: anything.com
    41  ```
    42  
    43  For each of these requests, Janus detects that their URI is prefixed with one of
    44  the API's `proxy.listen_path` values. By default, Janus would then forward the request
    45  upstream with the untouched, **same URI**.
    46  
    47  When proxying with URIs prefixes, **the longest URIs get evaluated first**.
    48  This allow you to define two APIs with two URIs: `/service` and
    49  `/service/resource`, and ensure that the former does not "shadow" the latter.