Hi Paul,
Ø What the issue is about is essentially a reverse operation. We need to match the path to a resource class...
Yes, that's what I am looking for.
Ø In the interim of any such functionality
Oh, I am surprised as I thought it is good REST style to use URIs where the resources shouldn't go over the wire. Hence, if I am supposed to do that, I need a way back from the URI to my object. I don't want to add redundant code - I have used the PATH annotation, use already the UriBuilder to map resources to URIs and hoped for a clean way back, thereby minimizing redundancy and bugs in my code (an own little mapper might get out of sync with the @PATH annotations if other developers take over/join team).
Ø 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.
That would be great! Yes, please send me some information so that I can do the reverse mapping. Thanks in advance!
Regards,
Vedran
Von: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Gesendet: Freitag, 28. Mai 2010 20:36
An: Lerenc, Vedran
Cc: users_at_jersey.dev.java.net
Betreff: Re: AW: [Jersey] Reverse Lookup
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<mailto: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