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