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