On Thu, Feb 4, 2010 at 7:37 PM, Geoff hendrey <geoff_hendrey_at_yahoo.com>wrote:
> Hi Craig,
>
>
> >If you add path segments ".." and "6" (or, more generally, the page
> >number you want to reference as the second segment), you should get
> >where you want to be.
>
> The problem with this is that I want to preserve matrix parameters. Also
> /page/5 might not be the last path. For example, I might see this:
> .../page;size=10/5/descending/date
> In these more complex scenarios, the simple approach of frobbing the last
> path segment doesn't work.
>
>
Well, we're going to have to agree to disagree. To me, trying to use URIs
for this kind of thing (versus query parameters) is not a good design. I
much prefer to use URIs to identify "what" and query parameters to identify
"how" a particular resource should be returned. Polluting URIs with
view-specific factors like "page number" and "sort order" and so on is
really going against the grain of how I think of RESTful resources. To say
nothing of complicating life for non-browser clients who want to integrate
with your application.
> I hope you can consider my suggestion, as I truly think addOrReplaceSegment
> (or maybe putPathSegment) would be an incredibly valuable method. For now, I
> will carry on with my utility class based on regex and string replacement.
>
> It's not up to me :-) since I don't work on the Jersey team, and don't even
work for Sun any more. But, even if JAX-RS offered this sort of thing, I
would never use it for the purpose you describe. URIs should be opaque to
clients, but server side logic, at the end of the day, needs to understand
how they are constructed; and, at the end of the day, it's your
responsibility as a server side developer to properly encapsulate the logic
that has to understand the details of your particular scheme. If I was
handed requirements that forced me to vend URIs like the ones you described,
I'd just encapsulate that logic in a helper class that started from
UriInfo.getBaseUriBuilder(), with convenience methods for the common URI
patterns, and at least encapsulate those details all in one place. That
kind of an app could be deployed today.
Also, since UriInfo and UriBuilder are part of the JAX-RS API, and not
specific to Jersey, the real audience you need to convince is the JAX-RS 2.0
expert group, once it is formed.
>
> Cheers,
> geoff
>
> Craig
>
> --
> http://nextdb.net - RESTful Relational Database
> http://www.nextdb.net/wiki/en/REST
>
>
> --- On *Thu, 2/4/10, Craig McClanahan <craigmcc_at_gmail.com>* wrote:
>
>
> From: Craig McClanahan <craigmcc_at_gmail.com>
> Subject: Re: Re: [Jersey] can we get a UriBuilder.addOrReplaceSegment
> method? Tuesday, February 2, 2010 11:51 PM
> To: "geoffrey hendrey" <geoff_at_nextdb.net>
> Cc: users_at_jersey.dev.java.net
> Date: Thursday, February 4, 2010, 7:21 PM
>
>
> On Thu, Feb 4, 2010 at 6:45 PM, geoffrey hendrey <geoff@nextdb.net<http://mc/compose?to=geoff@nextdb.net>>
> wrote:
> > Hi Craig,
> >
> > I don't want a new view of the same resource. For example, consider a URI
> > like "/page/5". The resource for page 5 wants to be able to create links
> to
> > /page/4 and /page/6, it is extremely useful to be able to say
> > addOrReplaceSegment("/page/{page}", "6"). I can even envision a syntax
> like:
> > addOrReplaceSegment("/page/{page}", "${page}+1") but that's above and
> beyond
> > what I need.
> >
> > I hope I won't see a response saying "page numbers should be query
> > parameters" since at that point the issue drifts toward the religious
> rather
> > than the practical. There are many reasons, such as availability of
> matrix
> > parameters to the path segments, or behaviors of web caches, that make
> path
> > parameters preferable in some situations. I just want an easy way to take
> a
> > resource's URI and mutate its path parameters so that I can easily create
> > links to similar resource. So far, virtually everything else is a dream
> with
> > Jersey and JSR-311, but this is one place where I think it could be
> > improved.
>
> It's too bad you don't like query parameters for this ... the
> queryParam() method on UriBuilder would be just the ticket :-).
>
> A not-recommended alternative would be to start from
> UriInfo.getBaseUriBuilder() and build the whole thing up from scratch.
> That would be spreading knowledge of how your uris are constructed
> all over the place.
>
> A better option might be to consider
> getBaseUriBuilder().path(MyResourceClass.class) that will give you the
> path matching the @Path declaration on your current resource class.
> Then, you only have to add path elements for the last part.
>
> If you really want to start from getAbsoluteUriBuilder(),assume you're
> on page 5 with a path like:
>
> ...../pages/5
>
> If you add path segments ".." and "6" (or, more generally, the page
> number you want to reference as the second segment), you should get
> where you want to be.
>
>
> Craig
>
> >
> > Cheers,
> > geoff
> > --
> > http://nextdb.net - RESTful Relational Database
> > http://www.nextdb.net/wiki/en/REST
> >
>
>