request help: Parameters in path

[membphis]

original issue: apache/apisix#2058 (comment)

For the "*" syntax, my understanding is that "*action" is an optional parameter. For example if we configure "uri": "/:id/foo/action/bar" in APISIX, both requests "/1/foo/get/bar" and "/2/foo/bar" should be matched by the route, while request "/3/foo/a/b/bar" should be rejected. However in APISIX the "" syntax has similar behavior with the colon syntax. The tests 7, 8 here https://github.com/api7/lua-resty-radixtree/blob/master/t/parameter.t seems broken: they are named "/name/*name/foo" but tested with "/name/:name/foo"

[membphis]

@Gary-Airwallex we can talk it here.

I think that is a bug. we need to fix it.

[membphis]

I did some research about *, I think the current way is correct.

We support * is same as gin, here is the official link: https://github.com/gin-gonic/gin

And here is the Chinese article: https://studygolang.com/articles/29177

// 例子3. 带星号（*）模糊匹配参数的url路径
// 星号代表匹配任意路径的意思, 必须在*号后面指定一个参数名，后面可以通过这个参数获取*号匹配的内容。

//以/foods/ 开头的所有路径都匹配
//匹配：/foods/1， /foods/200, /foods/1/20, /foods/apple/1 
/foods/*path

//可以通过path参数获取*号匹配的内容。

//  (*) URL path of fuzzy matching parameters
// (*) means to allow any path,

// here is some example, route: /foods/*path
// will match all of them:

/foods/1， /foods/200, /foods/1/20, /foods/apple/1 


// and we can get the matched value by name `path`

[membphis]

For example if we configure "uri": "/:id/foo/*action/bar" in APISIX, both requests "/1/foo/get/bar" and "/2/foo/bar"

I think that is a wrong example.

"/:id/foo/\*action/bar" is an invalid format, it is difficult to understand that action/bar is a parameter name.

So, /:id/foo/\*action is easier to use. We should add more test cases about this.

[Gary-Airwallex]

Ok I see. Double checked in radixtree 2.2 with APISIX 1.5, seems like "/abc/*id" is rejecting requests "/abc" or "/abc/", which should be accepted according to the Gin docs (it might have something to do with APISIX's behavior on trailing slash?).

[Gary-Airwallex]

Is there any plan on supporting optional parameter as described in my example? (Such that both "/foo/bar" are "/foo/1/bar" by uri "/foo/SOME_OPTIONAL_PARAMETER/bar") It's not a must-have feature for us currently, but I think it'd be sweet to have it.

[membphis]

Is there any plan on supporting optional parameter as described in my example? (Such that both "/foo/bar" are "/foo/1/bar" by uri "/foo/SOME_OPTIONAL_PARAMETER/bar") It's not a must-have feature for us currently, but I think it'd be sweet to have it.

We do not have any plans for this case. I think we support Gin way is power enough. ^_^