Hi, comments line
>>>
>>> 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.
>> Well, Client is an entity which communicates with HTTP service using HTTP-centric mechanisms. IMHO, there are only 3
>> things Client needs to do:
>> - optionally set headers/query/etc parameters
>> - ask HttpService to GET or POST/etc, providing a payload body when needed.
>
> I agree that client is the entity managing the communication. Still I don't think the client should directly manage the
> customization of the request. Put everything into one single blob just for the sake of having a single blob is not a
> particularly effective design.
If you agree that "client is the entity managing the communication" than
IMHO it contradicts with your statement below that Client has no any
relationship to a particular Resource. It's a ***factory*** - that is
all it is in the current version. Thus IMHO it's misnamed but of course
we already have ClientFactory which happens to be the factory too
>> We do it in CXF, the indications are users do use it, and I haven't had yet anyone complaining about the complexity of
>> CXF JAX-RS client API or being limited (except that we don't do async support yet)
>
> I'm afraid that "CXF JAX-RS client API" is an oxymoron :) It's either CXF or JAX-RS. Anyway, let's stick to the
> technical discussion rather than arguing about what Jersey/CXF/Resteasy client API users complain or not complain about.
Marek - you misunderstand what "CXF JAX-RS" is and in the community
where people are aware of multiple implementations it's a well-known
fact that "CXF JAX-RS" is a shortcut for referring to the JAX-RS
implementation in Apache CXF project. Besides I was not referring to it
in order to argue - it was part of my case for attempting to refer to
the fact that simplicity can be achieved without extra complexity, no
more than that, thus I don't think your comment above is fare.
>
>> ClientFactory has to manage the 'non-free' bootstrapping process. In the current version we have a long chain of
>> factories. ClientFactory creates the Clients and a given Client cheaply works from them on.
>
> ClientFactory is just a common, standard entry point to the API. All the real bootstrapping should happen in the client
> instance at the creation time. We need to keep this in the client so that the different requirements on versioning and
> client implementation remain satisfiable in the containers with multiple running applications.
>
>>
>>> 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.
>>>
>> Please, explain me in leyman terms what is Client and what is Link
>
> Client is the place where all the heavyweight initialization happens. It is also the place holding the common
> configuration. It§s responsibility is to manage the communication infrastructure and create the lightweight objects,
> such as invocations and links. Client does not have any relationship with a particular resource.
>
IMHO it's totally misnamed. It's a factory and it is very confusing.
> (Resource) link provides an "access" to (or an identification of) a particular resource the user wants to work with.
> User can use a resource link to specify a resource or domain-specific configuration, derive links to sub-resources or
> create invocations targeted at linked the resource.
>
> Invocation represents a single HTTP invocation, targeted at a particular URI (resource). An invocation enables
> construction of the underlying HTTP request (entity, method, headers...) as well as support for further customization of
> a single invocation configuration (e.g. security, logging etc.). It also provides support for batched request execution
> using a command pattern.
>
> All of the above should be obvious from the proposal wiki. If it's not, please point me to the parts, that are missing
> in the proposal.
Sure. The above explanation is helpful. The problem with the current
version is that Client is misnamed, Link acts as a WEB Client but not as
Resource ID and the complexity spills into API.
HTTPRequest & Invocation are OK. Making Invocation a central piece if
API is the main problem IMHO.
Thanks, Sergey
>
> Marek
>
>> Thanks, Sergey
>>
>>> -- 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
>>>>
>>>>
>>>>
>>>>