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:
o This is a very common use-case (navigating links)
o The user doesn't really care about the Client. This is almost an
implementation detail for us (how often do we need multiple
Clients?).
o 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
> <mailto: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
>
>