On Aug 28, 2012, at 8:40 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 8/28/2012 12:43 PM, Marek Potociar wrote:
>>
>> In Jersey users typically use it to provision (fully-initialized and
>> properly scoped) sub-resource instances
>
> I just not certain this is a job for JAX-RS.
>
>> , regardless of what container
>> manages each particular instance, using the
>> ResourceContext.getResource(...) method. Another problem the users are
>> facing is that in many cases if a user wants to support more complex URI
>> spaces, it would make a lot of sense to leverage the JAX-RS matching
>> engine to internally "find" a proper resource instance or information
>> about it. For those cases the ResourceContext contains the matchXxx()
>> methods that expose the matching engine to the end user.
>>
>
> I've had the case that we implemeted where users want to do something like a Servlet.forward(), but I don't think this is the same thing. Can you give some examples of each match method? I'm just not understanding how it would be used.
I'll borrow the example from a recent post on our users forum:
Let's say you have a bookstore application that let you access books (book resources) via various URI schemes, e.g.:
/bookstore/books/{bid}
/bookstore/sections/{section}/books/{sbid}
/bookstore/authors/{author}/books/{abid}
...
Ideally, you want to have just a single BooksResource that handles all these URIs. So from sub-resource locators in your SectionsResource and AuthorsResource you could use the ResourceContext.matchXxx() methods to "find" the (properly initialized) instance of BooksResource without having to know too much about it. All you need to know is the main entry point to all books and the book ID. E.g.:
@Path("books/{id}")
public class BooksResource {
...
BooksResource getBook() { ... }
}
@Path("authors")
public class AuthorsResource {
...
@Path("{author}/books/{abid}")
BooksResource getBook(@Context ResourceContext rc, ...) {
String bookId = ... ; // get the book UID
return rc.matchResource(UriBuilder.fromResource(BooksResource.class).pathParam("id", bookId).build());
}
}
Obviously, you can use those methods to conveniently support URI graphs - from books resource you could easily navigate to authors or sections etc. Other, more advanced scenarios are possible too. Among the main advantages is that you don't need to know too much about the implementation details and initialization of those other resource and that you can avoid internal redirects.
Marek
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com