One approach you could use is subresource locators. E.g.
@Path("/users/{id}")
public class UserResource {
public UserResource(@PathParam("id") String id) {
// do whatever common work is required
}
@Path("some/sub/path/1")
public SomeSubPath1Resource getSubPath1Resource() {
// instantiate whatever kind of resource is appropriate
// based on work done in constructor
}
...
}
The getSubPath1Resource method returns an instance of a resource class to handles the actual request (e.g. a class with @GET, @POST ect methods.
Marc.
On Feb 24, 2010, at 9:51 PM, Trolly Rogers wrote:
> Hi All - Hope I'm not being a pest. I just can't figure out how to handle some common logic needing to be applied to a common path param (at least the way I'd like to). I have a bunch of resources which all share a couple things I mentioned below. There's basically one root resource, and a number of sub-resources exposed via method and locator. Here's the two things they all have in common...
>
> 1. part of thier URIs. They all begin with /users/{id}. The id is not the user's user id exactly, but it is a unique way to identify the user and provides a great piece of scoping info keeping my URIs RESTful.
>
> 2. The {id} path param needs to be checked against the value of HttpServletRequest's getUserPrincipal().getName(). This name is set as part of our security infrastructure and ensure the {id} passed to my resource is in fact the right user.
>
> I thought I was on to something when I was workin' on my own ResourceFilterFactory impl. The thing I got hung up on was how to get the value of the resolved {id} path param, is this possible in a ContainerRequestFilter?
>
> The solution I have working now is basically having my resource classes sub class "UserIdAuthBasedResource" which provides a constructor forcing any sub classes to pass in the user id and HttpServletRequest for the common checking (#2). There's obvious disadvantages here (but it works), any suggestions?
>
> Thanks,
>
> Trolly