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.