>>
>>> 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