Hi
On 27/08/11 16:06, [email protected] wrote:
I have a URL e.g. http://myhost.com/a/b/c
Now lets say b is matched by a resource method
class RootResource{
@GET
@Path("/b")
TypeX getB() {...}
}
and in class TypeX:
class TypeX{
@GET
@Path("/c")
String getC() {...}
}
While the URL http://myhost.com/a/b works as expected,
http://myhost.com/a/b/c not works (cause is not available). I think the
selection algorithm is already satisfied by having found the getB
resource method, and does not know what to do with the rest of the URL.
By inserting following method into RootResource, I have a workaround,
which is not very nice:
@Path("/b/")
TypeX getBAndGotoSubresource() { return getB(); }
@Path("/b")
TypeX getBAndGotoSubresource() { return getB(); }
without a trailing slash should also work, at least in 2.4.2
another option is to have only
class RootResource {
@Path("/b")
public TypeX getTypeX() {
return getB();
}
}
and have
> class TypeX{
@GET
TypeX {
return this;
}
> @GET
> @Path("/c")
> String getC() {...}
> }
So my question is: is here a bug or is that behavior specified by REST
spec?
Not a bug, resource methods having HTTP verb annotations are considered
to be final handlers. These handlers should match the last path segment
completely, which is not possible in case of /b/c being matched against
Path("/b").
Cheers, Sergey
