jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: Client API is very complex

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Fri, 01 Jul 2011 11:20:28 +0100

Hi,

Santiago Pericas-Geertsen wrote:
> 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.
>

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 do not quite share a concern that having Client managing these two
tasks creates an overbloated constructs which no one understands what it
does. Prepare the invocation context if needed and get/post/etc.

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)

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.


> 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

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