问题
I'm exposing an HTTP API through Play, and in order to manage compatibility-breaking changes, the URL contains the version number. At present this looks like the following:
GET /api/v1/someMethod com.foo.Api.someMethod()
As I introduce a change to the output of one of the methods, I'd like to support v2. For most of the methods though, the behaviour is identical, so I don't care which version is used. I tried to modify the above line to:
GET /api/v:version/someMethod com.foo.Api.someMethod()
But Play fails to compile this, with the error Missing parameter in call definition: version.
I know I didn't use the version parameter in the call - because I didn't need to! Is there a sensible way to achieve what I'm after here, either to get Play to skip this check, or to put a wildcard in the route that is not captured as a parameter?
(I suppose if not I could add the parameter to the method definition, and then ignore it. But I'd rather avoid that if possible.)
回答1:
Having played around with this for a while trying to find workarounds, I suspect it may not be possible.
The big sticking point is reverse routing. Play wants it to be possible for me to be able to use @routes.com.foo.Api.someMethod in my templates, and have it resolved to the URL that would invoke that method. (And in fact I do this in my API docs). If either of my above proposals were to be accepted, it would be arbitrary what the actual URL was that corresponded to the method.
I suppose what I really want is for the method to have a canonical URL, but for other similar patterns to be considered a match too. I accept that Play does not offer this as part of the relatively simple routes file syntax, and I'd have to accomplish it myself (e.g. by using two patterns, with the wildcard one ultimately but not directly invoking the same method).
来源：https://stackoverflow.com/questions/19975794/non-capturing-wildcards-in-play-framework-routes