Yeah, for me it is pretty simple to do what you are saying. I just create a
new target. I would never use my REST resource classes (CompaniesResource)
on my client side except maybe to get a path annotation for unit testing.
Your mileage may vary, but I found the 2.x API a VAST improvement.
On Wed, Apr 16, 2014 at 7:28 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> Hi Robert,
>
>
> On 16/04/2014 6:23 PM, Robert DiFalco wrote:
>
> Not sure what a WebResource is in 2.0 but isn't what you want to do as
> simple as:
>
> client.target( response.getLocation() );
>
>
> In Jersey 1 you just needed to keep a reference to a WebResource. In
> Jersey 2, you need to keep a reference to both a Client and URI.
>
>
> Or something equally simple? if it's relative you can use your existing
> target and just do something like:
>
> target.path( relPath );
>
>
> Unfortunately, I'm talking about an (absolute) URI, not a relative path.
> I'll give you a concrete (client-side) example:
>
> - CompaniesResource.get() invokes HTTP GET /companies
> - The method returns a List<CompanyResource>, one entry per company
> returned by the response.
> - Each CompanyResource contains its own WebResource.
> - In Jersey 1, it was enough for a CompaniesResource to hold a
> reference to its own WebResource in order to construct a CompanyResource.
> In Jersey 2 it needs to keep a reference to both the Client and its own
> URI. Two references instead of one.
> - Consider:
> - This is a very common use-case (navigating links)
> - The user doesn't really care about the Client. This is almost an
> implementation detail for us (how often do we need multiple Clients?).
> - A single Client is shared across multiple resources, yet we're
> forced to store one reference per resource.
>
> And finally... According to "How to Design a Good API and Why it Matters"
> found at http://lcsd05.cs.tamu.edu/slides/keynote.pdf
>
> If you open page 28 you will find:
>
> - Don't make the Client Do Anything the Module Could Do:
> - Reduce the need for boilerplate code
>
> I believe this falls under the category of boilerplate code.
> Gili
>
> On Wed, Apr 16, 2014 at 3:13 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
>
>> Hi,
>>
>> In Jersey 1.0 we could create one WebResource from another as follows:
>>
>> WebResource first = ...;
>> WebResource second = first.uri(newAddress);
>>
>> Naturally, when a resource returns a link we want to construct a new
>> resource using the new link using the same Client. By removing support for
>> this very common use-case, you are forcing users to re-implement this
>> themselves over and over again in their code.
>>
>> Why was this use-case removed in Jersey 2.0?
>>
>> Thanks,
>> Gili
>>
>
>
>