users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Apache HTTP Client + JAX-RS

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 20 Nov 2012 21:31:34 -0500

On 11/20/2012 2:51 PM, Jan Algermissen wrote:
>
> On Nov 13, 2012, at 5:34 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>> I actually think this is quite important to think about how Apache HTTP client effects JAX-RS. Specifically on the security stuff we're thinking about adding to the spec.
>>
>> For example, if you look at how you configure HTTPS and client-cert auth for Apache HC, you notice that you cannot really set things up on the fly, you can't really modify them on the fly either. These things need to be available before you make one connection with Apache HC client:
>>
>> * server truststore (for HTTPS)
>> * client keystore (for client-cert auth)
>> * In some situations a hostname verifier is needed.
>>
>> This is leading me to believe that simple security properties aren't gonna cut it and we're gonna need some builder API to bind security config to a Client or WebTarget. Basically a builder API says "I'm done configuring connection properties, you can build the DefaultHttpClient now!" I'm prototyping one at the moment and will be ready to propose something soon, but it would be cool to get your thoughts on this.
>
> That's an interesting aspect, too.
>
> My issues are with connection handling. Right now, ClientFactory.newClient() is IMHO just completely useless when you leave the playground and create production systems.
>
> Yes, one can configure the client after getting it, but that is probably too late.
>
> What is our story on this? Is it that JAX-RS 2.0 simply provides ClientFactory as a base interface and that our expectation is that implementations will extend ClientFactory with a more configurable subclass?
>
> E.g.
>
> PerThreadConnectionPoolAwareFactory factory = PerThreadConnectionPoolAwareFactory.getInstance()
>

So SSL, auth, connection-pooling, threadsafety, following redirects,
cookies: Are those all the most common "production" features?

> Client client = factory.getClient(); // to get a client using a certain upstream connection pool
>
> ...
>
> The provided ClientFactory interface in 2.0 would then really only be 'informative', not to be used in practice really.
>
> Would be fine with that, but I am interested in your opinion.
>

My thought was that you would always instantiate a client directly:

ResteasyClient client = new ResteasyClient();

Or, if you had a builder API

ResteasyClientBuilder builder = new ResteasyClientBuilder();

Unless of course you standardized a setup API for the "production"
features I just mentioned above.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com