Hi Santiago
I recall you clarified to me over Skype some of the subtleties related
to a situation where a matching algorithm has identified matching
subresource and subresource-locator method candidates. Sorry for
returning to it. I thought that given
POST /root/1
@Path("root")
public class Root1 {
@GET @Path("1") Response get() {...}
@Path("{id}") Root1Sub getSub() {...}
}
getSub() is discarded, we have 405.
but with
@Path("root")
public class Root2 {
@GET @Path("{id}") Response get() {...}
@Path("1") Root2Sub getSub() {...}
}
getSub() is selected and is given a chance to check if it has a POST
handler.
I've just re-read 3.7.2.2, (g) and (h) in particular, and it appears
that a sub-resource locator never gets a chance if there's a path match
on one of the current resource's methods such as "get()".
Is that right ?
If so - what is the point of 3.7.2.2.f continuing with "and the source
of each member as quaternary key sorting those derived from sub-resource
methods ahead of those derived from sub-resource locators." ? I.e - a
subresource locator is never going to be selected if at least one
(sub)resource method has a matching path with an empty final group...
Thanks, Sergey