users@jersey.java.net

Re: [Jersey] Handling URIs in the body of a message from the server-side

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 30 Sep 2009 12:04:36 +0200

Hi Andrew,

You can use Jersey's UriTemplate [1] to match the URIs in the
representation. But first i think it best to first strip off the base
URI (UriInfo.getBaseUri) so that you match against paths.

Then the question becomes where to obtain the templates to use. You
might be able to reuse the templates on the resource classes
themselves. But if not you may have to utilize your own template
(which makes things less DRY).

This use case is IMHO related to that of better supporting hyperlinking.

Paul.

[1] https://jersey.dev.java.net/nonav/apidocs/1.1.2-ea/jersey/com/sun/jersey/api/uri/UriTemplate.html


On Sep 30, 2009, at 12:02 AM, Andrew Ochsner wrote:

> Hi:
>
> This probably more of a conceptual question, and if it's already
> been covered, just let me know. I couldn't find anything doing some
> quick searches...
>
> I'll just start with an example.. Let's say I'm POSTing an Order
> (which is a list of items and quantity). I think the most "RESTful"
> way of doing this would be...sure there are other ways but this is
> just what we're thinking of...
> POST /orders
> { "items" : [{ "item" : "http://server/path/to/item/12", "quantity":
> 2 }, { "item" : "http://server/path/to/item/21", "quantity":3 }]}
>
> What's the best approach to resolving those URIs? In my case, I own
> (and don't forsee not owning) the URI space/Resources for Items as
> well. And ultimately I just care about the last part of the path
> (12 & 21) so I can look it up in a database....
>
> Ideally I'd like to utilize (in some way...no idea) the Path
> matching that already happens when a client does a GET /items/21
>
> The simplest but maybe the most brittle would be to just chop off
> all of the path but the last part
>
> Most generic approach would be to just use the Jersey client (or
> some other http client) to GET that URI...but not sure it's worth
> whatever performance issues that may cause (heck it might not cause
> any...that'd be cool)...
>
> Is there anything in between?
>
> Thanks in advance
> Andy Ochsner