On Jul 5, 2011, at 10:41 AM, Sergey Beryozkin wrote:
>>
>> 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()
Suppose there's a need to set a query param for the get() but not the post(). Would you set it in your link first and then clear it before the post() is executed?
>> 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
So your suggestion is simply to add a convenience method to Link to accommodate a common usage pattern?
-- Santiago