Hi Marc,
IMO this is good.
And IMO "GET /foo//baz" -> @Path("foo/{bar}/baz") is not a good style,
so why support it.
If it should be supported, we could add an attribute to @Path, which
switch between at least zero or at least one character (boolean or an
int with the minimum number od characters).
best regards
Stephan
Marc Hadley schrieb:
> Currently a template variable matches *zero* or more characters in a
> request URI, e.g.:
>
> @Path("{foo}")
> public class Foo {
> @GET
> public String getFoo(@PathParam("foo") String foo) {return foo;}
> }
>
> GET /1 => "1"
> GET / => empty
>
> An issue has come up on the Jersey mailing list a few times recently
> that results from the lower bound of the matching. Consider:
>
> @Path("bar")
> public class Bar {
> @GET
> public String getBar() {return "bar";}
>
> @GET @Path("{foo}")
> public String getFoo(@PathParam("foo") String foo) {return foo;}
> }
>
> GET /bar => "bar"
> GET /bar/1 => "1"
> GET /bar/ => empty
>
> The problem is that the final request gets mapped to the getFoo method
> which surprises developers.
>
> To fix this we propose to change the rules such that a template
> variable matches *one* or more characters in a request URI. With this
> change the results for the example above become:
>
> GET /bar => "bar"
> GET /bar/1 => "1"
> GET /bar/ => "bar"
>
> The above matches developers expectations more closely but its worth
> noting that the change will have consequences. E.g.
>
> GET /foobaz will no longer match @Path("foo{bar}baz")
>
> and
>
> GET /foo//baz will no longer match @Path("foo/{bar}/baz")
>
> On balance though we think this change is the best compromise.
>
> Thoughts, comments ?
> Marc.