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 ?
>
>>> 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.
>
It's a factory->request, do you see any real difference between passing
Invocation and factory of invocations around ?
>> 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.
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 ?
Sergey
>
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com