On 7/5/11 9:02 AM, Sergey Beryozkin wrote:
>>>> I disagree. Link should be a request factory, thats it. If you have
>>>> anything even slightly complex, an Invocation will need to get created
>>>> anyways, i.e. if the Link is a uri with path parameters or if you want
>>>> to set a specific query parameter. Also, with a post, or put you'll
>>>> want to set the entity body, form parameters, etc. Besides all you're
>>>> saving is:
>>>>
>>>> link.request().get();
>>>>
>>>> vs.
>>>>
>>>> link.get()
>>>>
>>>> Not a big deal, IMO.
>>> link.get().invoke() is a big deal IMHO :-)
>>>
>>> Of course I was not assuming only plain get() can be done. Current API
>>> is Invocation-centric. And Invocation is primarily there to accommodate
>>> batch-processing and such. I'd like to see Invocation not visible at all
>>> except for those users who know why they need Invocation.
>>>
>>
>> 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.
> 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
5) An async get and post with examples 1-4
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com