On May 13, 2008, at 11:55 AM, Sergey Beryozkin wrote:
>
> So taking the example I provided, would the 'descending order' bit
> still result in a readBar being selected() for requests like /1/ ?
>
No, because that only applies to selecting the object that will handle
the request. Choosing amongst the methods of the chosen object is then
done in bullet three. Essentially the algorithm has three parts:
1. Find the root resource class
2. Traverse sub-resource locators
3. Find the method
Sorting by literal template characters and capturing groups on happens
in 1 and 2.
> @Path("/{a}")
> public class FooClass {
>
> @GET
> @PATH("/")
> public Bars listBars() {...}
>
> @GET
> @PATH("/{e}")
> public Bar readBar(@PathParam("e") String e) {
> }
> }
>
> readBar() has 1 capturing group so wins here as it goes first. The
> number of literal characters is the same in both cases (just '/').
> Should we have 'the number of capturing groups as a secondary key
> (*ascending* order)' instead ?
> What do you reckon about the feasibility of (.+)? being introduced ?
> This will lead to no uncertainties at all in this case ?
>
I'm beginning to think that this would be the best solution but I'd
like to think about it some more. There are some downsides to consider
too, e.g.: @Path("foo{ext}") would no longer match "foo" so you'd need
extra methods or classes to handle optional path parameters.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.