Sergey,
I believe that if you push all the functionality that you suggest into Client, the result is a bloated class whose purpose isn't clear anymore (I think this was on the table at some point). So far the assumption has been that (see bootstrapping process) creating instances of Client isn't free, and thus the separation of concerns seems sound.
Client, Link and HttpRequest/Invocation have clearly defined roles in the API. The HttpRequest/Invocation pair exists so that handlers and filters can work on HttpRequest instances that are not invocable.
-- Santiago
On Jun 29, 2011, at 8:37 AM, Sergey Beryozkin wrote:
>>>
>>>> 3. Link **is** effectively a Client even though Links are supposed to be identifiers of resources Clients are supposed
>>>> to work with.
>>> I did have this design at one time, but then I got a feedback that I am missing the instance to hold expensive
>>> initialization.
>>>
>> The current Link abstraction is very nice because you can configure things like security for a specific resource that you are going to invoke on more than once. YOu can also pass Link references around without also having to worry about passing Client references as well.
> My major concern is that overall it is complex. Too many factories.
> Link is a Client and IMHO, despite the fact it may sound controversial, Link is 'over-engineered' and redundant, as far as its role of creating invocable HttpRequests is concerned.
>
> IMHO
>
> Client must be the thing which manages the invocation and Client is the entity which drives it and Client. Client must be able to act as a builder. By implementing Invocable or similar it can be passed around and consumed by generic executors.
>
> Client will have get()/post() and friends and it will be simple and easy to understand - client will GET something, client will POST something to a resource URI/Link.
>
> Client will have a method such as toInvocable(String httpMethod) or similar so that it can be optionally converted to Invocation and queued if needed.
>
> Client will act as a builder and be able to spawn new Clients for dealing with subresources. If Client needs to move away to a new absolute URI then ClientFactory can cheaply create a new Client.
>
> Dynamically adding features to existing Clients is complex and makes it difficult to make an injected Client reference thread-safe.
>
> ClientFactory manages expensive initialization and such.
>
> I'm worried about users being forced to write a generic invocation code
>
> Sergey
>
>
>
>