Hi,
What the issue is about is essentially a reverse operation. We need to
match the path to a resource class, and the only way to do that is to
make a pseudo-internal request, because sub-resource locators can be
invoked that partially matches the path.
So we can avoid instantiation of a root resource class if the path
matches the root resource and (if any) a sub-resource locator or sub-
resource method, but if further matching is required the resource
needs to be instantiated and the sub-resource locator invoked.
In the interim of any such functionality i can provide details of a
way of obtaining the URI templates for the set root resources (and
templates for sub-resource locators and sub-resource methods), and
from that you can concoct your own reverse matching. I can send more
details as required.
Paul.
On May 28, 2010, at 6:11 PM, Lerenc, Vedran wrote:
> Hi Paul,
>
> I am not quite sure if it helps me. I basically look for the reverse
> operation of UriBuilder.fromResource() that turns something like “/
> cars” into Car.class.
>
> My problem in an example:
>
> Let’s say I have a class User and a class Car with an 1:N
> relationship and let’s say I expose both as REST resources with the
> paths /users and /cars.
>
> When I send a user over the wire as response to a GET, I don’t want
> to send all cars along (there may be many), but keep to good REST
> style (I hope it is) and just put the URIs to those cars into the
> response body, e.g.
>
> <user>
> <id>123</id>
> <name>John Doe</name>
> <cars>
> <car>/car/444</name>
> <car>/car/555</name>
> <car>/car/777</name>
> </cars>
> </user>
>
> I create the URI with UriBuilder and then put them in instead of the
> fully serialized cars. Now, if someone takes such a user and removes
> one car or adds another, I get something similar back with the PUT/
> POST. In this case I need to resolve the URIs back to the real
> objects and for that I need to know that “/car” is a resource of the
> Car.class. Jersey knows that. It did the transformation to “/car”
> based on the @PATH annotation, but how can I programmatically turn “/
> car” into Car.class without making a full REST call? Is there and
> what is the reverse operation of UriBuilder.fromResource()?
>
> Thanks in advance,
> Regards,
>
> Vedran
>
>
>
> Von: Paul Sandoz [mailto:Paul.Sandoz_at_Sun.COM]
> Gesendet: Freitag, 28. Mai 2010 17:30
> An: users_at_jersey.dev.java.net
> Betreff: Re: [Jersey] Reverse Lookup
>
> Hi Vedran,
>
> There is an open issue for this and i know others need this
> functionality:
>
> https://jersey.dev.java.net/issues/show_bug.cgi?id=536
>
> I need to think more on how such pseudo-internal requests should
> work as such requests will be different to that of requests
> originating from the client. For example should such pseudo requests
> re-use all the headers of the original request, or just a meaningful
> subset (e.g. Authenticate?)
>
> However, apart from such details i think it should be fairly easier
> to adapt the current matching functionality.
>
> Paul.
>
> On May 28, 2010, at 12:55 PM, Lerenc, Vedran wrote:
>
>
> Hi,
>
> I am new to Jersey and try to generically use it in combination with
> Hibernate and XStream. When I send an resource object over the wire
> I use XStream for serialization and when this resource object
> contains references to other resource objects, I replace them with
> the resource URI instead of serializing them. This works quite good
> with the help of the UriBuilder (e.g.
> UriBuilder.fromResource(type).path(type,
> "getById").build(id).toString()).
>
> However – and that’s my question – how can I get the resource class
> back from the URI (e.g. /cars/123). Jersey does it once for the
> containing resource when the REST call hits it, but then I am on my
> own while deserializing the content. I must take an URI that I have
> built with the help of the UriBuilder and get the original resource
> class back. Does anybody know how to do this lookup from URI to
> resource class?
>
> Thanks in advance,
>
> Vedran
>
>