On 09/09/11 15:09, Marek Potociar wrote:
>
>
> On 09/09/2011 02:07 PM, Sergey Beryozkin wrote:
>> Hi Marek
>>
>> I definitely did not mean to indicate anything like that - and besides, the spec is moving ahead very well...And of
>> course we appreciate that a lot of effort is going into it behind the scenes.
>>
>> Agreed about humans being much more capable re treating arbitrary responses and such. I was kind of trying to indicate
>> that API should have something called 'Client' as its central, active entity. Right now we do have Client which is a
>> factory, and it's a job of the Target(s) to navigate across the application paths whereas in the real world it's
>> responsibility of the Client to go from here to there or from there to here and read or post something. The latter is
>> somewhat possible to express with
>>
>> client.target("http://bar").request().get()
>> client.target("http://bar/1").request().get()
>> client.target("http://bar").request().get()
>>
>> the above shows what I'm after: *Client* goes to http://bar, then this Client moves along to http://bar/1. Then decides
>> to go back. This is how the human works but the above captures it well.
>
> You can do the above with existing API. It's perhaps unfortunate that we spend so much time on Target as it seems to
> give wrong impression that Client is redundant. In fact it isn't. Behind the scenes, it's Client implementation that
> kicks in when a request is executed.
>
> Target was primarily introduced as a concept of encapsulating configuration of a single resource. It was designed with
> ability to derive other targets typically located in the same URI hierarchy tree. This seems more effective and more
> accurate model compared to a design where all the configuration is centered only in the Client, mainly because every
> client instance has to do some heavy lifting setting up the common communication infrastructure. So we decided to
> decouple the resource-specific (as well as request-specific) configuration from the Client.
>
>>
>> Of course,
>>
>> Target t = client.target("http://bar");
>> t.request().get();
>> t2 = t.path(1);
>> t2.request().get();
>> t.get()
>>
>> is equivalent but what I was saying that I'm not seeing something called a Client being the active entity here.
>> That is academical - but I hope you see what I mean
>
> I think I do, but I still prefer the fluency over the explicit declaration of which component is actually doing the
> execution. Besides, you can stick to the client-centric code style if you prefer it more.
That is not possible with the current api, to have a client-centric
style, that was my point. Client in the current api is no more than a
factory. My initial example above was only there to clarify what I was
after...
Thanks, Sergey
>
> Marek
>
>>
>> thanks, Sergey
>>
>>
>> On 09/09/11 11:02, Marek Potociar wrote:
>>> Hi Sergey,
>>>
>>> I don't want to sound arrogant, but it's not that I took the first API design that popped up in my head and pushed
>>> strong for standardizing it. I spend long hours going back and forth considering all the EG suggestions, trying
>>> different approaches and evaluating the PROs and CONs. At one point I did consider the "floating" Target idea too. But
>>> in the end it did not seem the right design choice. Disregarding some of the technical objections for now, the purpose
>>> of the API is to enable building non-human web service clients after all. Those clients have very different
>>> characteristics from human clients. They are typically programmed (by humans) to do specific tasks with specific web
>>> services, not to browse merrily back and forth exploring the web on their own. After all, programmatic clients don't
>>> have the ability to interpret arbitrary response data the way humans do. At least not yet. That's why I find the less
>>> "fluid" design preferable when it comes to low-level API.
>>>
>>> Marek
>>>
>>> On 09/08/2011 05:50 PM, Sergey Beryozkin wrote:
>>>> OK, lets just drop it. Not sure yet if I'm disappointed or not.
>>>> I guess what seem like naturally useful properties to me is hard to add with those possible issues to do with
>>>> stacks/lists/possible leaks. I accept though developers can live without the explicit support.
>>>>
>>>> One thing I'd encourage you to do is, without any commitments, try and prototype during a spare hour or so :-) another
>>>> version of API, the one which would attempt to approach it all with the assumption that this API represents a consumer
>>>> exploring the RESTful application, capture the usual browser experience.
>>>>
>>>> I know we are doing it for developers to write the code - but I'm thinking that ideally the api would capture somehow
>>>> the way the user works because it a typical way a restful application is explored.
>>>>
>>>> The current API is strong in its own way - just feels a bit procedural to me, as far matching that user experience is
>>>> concerned.
>>>> Sorry if I sound unclear or academical, etc :-), just wanted to express that - who knows - may be API can still be moved
>>>> forward somehow
>>>>
>>>> thanks, Sergey
>>>>
>>>>
>>
>>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com