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

[jsr339-experts] Re: Updated Client API and Interceptors/Filters proposal is available - please review

From: Guilherme Silveira <guilherme.silveira_at_caelum.com.br>
Date: Mon, 6 Jun 2011 19:06:29 -0300

> - I don't like all the getFeature() methods.  Just have a getProperties()
> method and be done with it.  I don't think I've ever seen such an API in
> Java EE before or what you're trying to accomplish with it.
I don't use it in Java EE but in other apis we use features to
customize any kind of api behavior. In this case, for me, Interceptors
are one type of features so:

new DefaultConfiguration().with(MyResponseFIlter.class).with(new
MyResponseFilter()) would be a way to configure it. It doesnt mean
that ResponseFilter inherits from Feature, but I like avoiding Strings
as much as possible for configuration.

Regards

Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/



On Fri, Jun 3, 2011 at 4:22 PM, Bill Burke <bburke_at_redhat.com> wrote:
> Some initial things.  I'll fork on github again with my suggested changes to
> give you more precise feedback.
>
> - I don't get the point of having Client be an abstract class. Expecially
> since all non-static methods except close() and finalize are abstract
> already.  I suggest making ClientFactory an abstract class and making Client
> an interface.
>
> - I still don't get the point of the HttpRequest.builder()  I know what
> you're trying to do there as per previous email threads, but consider this
> case:
>
> I think that you'll still want to the ability to change the request's method
> within an interceptor.  For example, there may be various services that
> tunnel DELETE and/or POST requests through a header or query parameter.  You
> may want to abstract this away from the client so that client code is still
> using a delete() call, but an interceptor is changing it to a POST with a
> query parameter.
>
> - Why does this method return a future?
>
> <T> Future<T> start(InvocationCallback<T> callback);
>
> To make it cancelable?
>
> - You don't need the InvocationCallback's getType() and getGenericType()
> methods.  The generic information is available from the getClass() method of
> the callback instance object.
>
> class MyCallback implements InvocationCallback<List<String>>
> {
> ...
> }
>
> Type type = callbackObject.getClass().getGenericInterfaces[0];
>
> - InvocationCallback's Javadoc should specify that the generic type can be a
> HttpResponse or entity type.
>
> - I don't like all the getFeature() methods.  Just have a getProperties()
> method and be done with it.  I don't think I've ever seen such an API in
> Java EE before or what you're trying to accomplish with it.
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>