Marc Hadley wrote:
> The @UnmatchedPath annotation was intended to be used to provide access
> to the unmatched part of a URI path thus:
>
> @UriTemplate("folders")
> public class Path {
>
> @HttpMethod(GET)
> public Response getContent(@UnmatchedPath String path) {
> ...
> }
> }
>
> On further thought we think a cleaner and more intuitive solution would
> be to add a property to UriTemplate that would enable "greedy" (can
> anyone think of a better word) matching for a terminating URI template
> parameter. E.g.
>
> @UriTemplate(value="folders/{path}" greedy=true)
> public class Path {
>
> @HttpMethod(GET)
> public Response getContent(@UriParam("path") String path) {
> ...
> }
> }
>
> Using the above and a request for folders/foo/bar, the value of path
> would be "foo/bar".
>
> Thoughts, comments ?
I prefer the new version for the API. However, if I read the uri
templates draft right, I think greedy is the default - it doesn't
support any operators/quantifiers but says any legal URI tokens can go
inside the brackets. So if I had (assuming greedy)
@UriTemplate(value="folders/{path}")
I'll match this - "folders/*". if I added another tenmplate pattern
@UriTemplate(value="folders/{path}")
@UriTemplate(value="folders/{path}/{subpath}")
then "folders/*" could go to either; ie, what gets called depends on the
order they're invoked - unless we're saying implementations are expected
to resolve this.
With a greedy operator in play, the call order could be changed as well,
assuming we did this
@UriTemplate(value="folders/{path}")
@UriTemplate(value="folders/{path}/{subpath}
and this
@UriTemplate(value="folders/{path}" greedy=true)
@UriTemplate(value="folders/{path}/{subpath}
what gets called changes subject to implementation details.
I think this means a) order of template evaluation matters, b) we need
test cases.
cheers
Bill