>>>>
>>> And I'm saying that most users will need to interact with an
>>> Invocation: to set path parameters, query parameters, headers, entity
>>> bodies, etc. Having multiple ways to do the same exact thing increases
>>> complexity and confusion. I just don't see yet how stuffing additional
>>> methods into Client/Link will make things much simpler.
>>>
>>>
>> Sure.
>> Imagine Link acts as Invocation. It acts as a builder and finishes with
>> get/post/etc thus effectively acting as Invocation. But the big
>> difference is that we don't have yet another factory (Link is a factory)
>> and the api flow is becoming HTTP-centric.
>>
>> Invocation does not add anything extra but invoke(). But it forces
>> get().....invoke() pattern which has very little to do with HTTP
>> programming IMHO.
>>
>> I understand why Invocation is there. But it does not mean Invocation
>> needs to become the central piece of this API.
>>
>> ClientFactory->Client->Link->Invocation.invoke()
>>
>> is a way too long a chain.
>>
>
> Well, right now, the usual case will be
> ClientFactory->Client->Invocation.invoke()
>
> Links exist to specify a base URI where you might want to add additional
> config to re-use, i.e. security. I also see Links, in the current model
> being returned as a value of a Link header, or embedded in a XML/JSON
> document. This is where this construct will really shine.
Sounds good, I don't think offering a shorter path from Link to
get()/etc will contradict.
All I'm saying is that Link should become the central piece of API.
If I get a Link from some custom document or header then I think it
would be nice to start immediately gliding forward/backward starting
from this Link, using it directly, without having to spawn Invocations,
unless needed.
Then you can do
myLinkPointingToCollectionResource.get()
myLinkPointingToCollectionResource.post(new CollectionMember());
myLinkPointingToCollectionResource.get()
as opposed to having to create multiple Invocations representing get,
post, etc:
Invocation getInv = myLinkPointingToCollectionResource.get();
getInv.invoke();
Invocation postInv = myLinkPointingToCollectionResource.post();
// use postInv
//use getInv again
I don't propose to drop Invocations by the way
>
>> ClientFactory->Client->Link
>>
>> is nice IMHO.
>>
>
>
> With your model here, can you give examples of:
>
> 1) A post with form parameters
> 2) A post with an entity body
> 3) A get with query parameters
> 4) A post or get with path parameters
same as with Invocation at the moment
> 5) An async get and post with examples 1-4
>
>
Have to think about it...
Cheers, Sergey
>