On Thu, Dec 9, 2010 at 9:09 AM, Christopher Piggott <cpiggott_at_gmail.com> wrote:
>> 2) The sub-resource locator, that returns a resource for further path
>> matching, should not be annotated with an @GET method.
>
> Hmmm, so the subresource can't support different methods for GET,
> POST, etc.? Does it have to be a class with essentially one method
> (or one per path selector)?
>
Sorry. I misunderstood your response, you said no @GET on the
LOCATOR, not the sub-resource. I get it now.
I like the jersey @InjectParam approach better, but both ways seem to work.
Thanks!
Now, if my root resource has a method that matches /item/123 and hands
it off to the sub-resource:
@RequestScoped
@Path("/items")
public class TopResource {
@Path("{itemId}")
public SubResource getPlatform(@InjectParam SubResource sub)
{
return sub;
}
}
@RequestScoped
public class SubResource {
@GET
@Path("{itemId}")
public String get(@PathParam("itemId") int itemId)
{
return "Your item is " + itemId;
}
}
This still doesn't work as I wanted, because the path to the sub
resource is /item/123/123 not just /item/123 ... what's the "right"
way to fix this, without forcing the sub-resource to have to parse out
the URL again?