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.
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
>>>
>>>
>
>