On 7/8/11 8:48 AM, Sergey Beryozkin wrote:
> Bill Burke wrote:
>>
>> 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.
>>
>
> Can RestEasy have HttpResponses keeping the original Client
> references/info ? The code where Client start driving the process is
> easy, what about the other example, where HttpResponse starts the process ?
>
Yes. HttpResponses in resteasy know which Client they were created from
and initialize links appropriately.
> It's a factory->request, do you see any real difference between passing
> Invocation and factory of invocations around ?
>
Yes, there's a big difference. You pass around Invocation instances so
you can implement things like batch processing and the Command Pattern.
You pass around Links to provide a reference to a resource. A
resource you might invoke separate and different HTTP invocations on.
i.e. when you embed it in a document, or within a Link header.
>>> 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.
>>
>
> It does not have to. It just becomes a bit adhoc. Client does one thing,
> Link does something else, Link is effectively a Client.
>
In current model, Link is essentially a Client with a pre-initialized
base URI to build requests from. But, Link is also a child of the
Client that created it.
> As far as Link is concerned, what we have at the moment is that it:
> 1. captures URI it represents
> 2. acts as a factory of invocations
> 3. capable of modifying URI
>
> 2. is problematic, can you at least accept that Client.request(Link)
> works ?
>
Why would you ever want to do Client.request(Link)? If you have a Link,
you can just create the request from there. You're creating problems
that just don't exist.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com