On 7/8/11 8:24 AM, Sergey Beryozkin wrote:
> Hi Bill,
>
>>
>> Sergey, client.request(link) is no different than
>> client.request(uribuilder) IMO.
>>
>
> Link is Configurable and it will have more associated metadata around
> URI, describing what this Link is 'about'.
>
>> You will also want to use Link interface as it current exists, for
>> link headers and the hypermedia framework.
>>
>> so, you could do:
>>
>> HttpResponse res = client.request(...).get();
>>
>> res = res.getLinkHeader("edit").request().post();
>>
>> or, with a hypermedia API like Restfulie:
>>
>> Customer cust = client.request(...).get();
>> client.links(cust).getLink("edit").request().post();
>>
>
> That looks nice. One problem I see is that the code like this:
>
> httpResponse.getLinkHeader("edit").request().post();
>
> is going to lose Client's features/etc (unless response itself keeps
> track of the original Client/Invocation) and IMHO original Client's
> features must be in scope unless overridden.
>
In resteasy we do this very thing. The Link inherits/is-created-from
the Client that originated the request.
>> With your approach of Link *NOT* being a request factory, you'd have
>> to interact with the Client object.
>>
>
> OK, the fluent style involving Links looks good. That said
>
> Client.request(Link)
>
> needs to be there IMHO.
>
>
> One other problem with Link having factory methods is that it prevents
> it from being passed around. We have HttpRequest and Invocation.
> Invocation is invocable HttpRequest and I can see why API wants to
> prevent custom filters and such from doing invocations.
>
How can you not pass around a Link? A Link is not a request, its a
glorified URI. Of course you can pass it around! At least with the
current model.
> Link with factory methods letting creating Invocable invocations is a
> problem, same way HttpRequest with get(), etc, would be.
>
> Thus, having
>
> client.request(httpResponse.getLinkHeader("edit")).post();
>
> instead of
>
> httpResponse.getLinkHeader("edit").request().post();
>
>
> does not look that bad at all IMHO, because:
>
> - It's easier to push original Client's configuration to the Invocation
> being initialized from Link.
> - Passing Link around won't have unexpected sideeffects
> - It's more obvious that Client is in control
>
My understanding of the current model was that Link inherits the
features/properties of the CLient it was created from.. Those
features/properties are overridable by the Link.
Why does it need to be obvious the Client is in control? The *LINK* is
in control as the Link is allowed to override features/properties it
inherited from the Client.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com