Hi
Santiago Pericas-Geertsen wrote:
>
> 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?
I think it's a good question which shows some limitation of the above code, but the same would apply to a case where we have a "get" Invocation which needs to do multiple queries with query values changing between requests.
IMHO the above 'binds' closer to the way typical user works with a given resource, either via browser or the client code
>
>>> 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?
I'd like to have Link acting as a builder and the entity which finalizes the chain with get()/etc. Guess something similar to what Bill prototyped in his proposal,
but without Invocation being there. Catching up on API details...
Cheers, Sergey
>
> -- Santiago
>