Hi Bill,
I think this is very similar to the changes I have currently in my local sandbox that I have made based on the EG
feedback so far.
There are few differences:
- I like the way you simplified the WebResource API and gave it more constrained purpose
- your proposal is full of interfaces. I like it for it's cleanness, esp. while still without javadoc :-), but do we
really want to stick to these interfaces forever without the ability to add any new methods?
- I don't see how you plan to instantiate the Client
- the need for the extra .execute() and .resolve() method is something I find redundant
- your request builder pattern can lead to "illegal" states which I find really unacceptable. The final API simply
cannot let me write this code:
ClientRequest request = client.request("
http://localhost:9095/customers/{id}");
ClientResponse response = request.pathParam("id", 123).execute(); // which HTTP method was executed?
The above code is IMO the tax for the reduced number of classes in the proposal. Also the fluent builder API suffers
greatly. In the days of IDE being the prevalent coding tool, I want the API provide the best code completion possible
and I want to let user to write the fluent code that will *not* allow for this:
ClientRequest request = client.request("
http://localhost:9095/customers/{id}");
ClientResponse response = request.get().pathParam("id", 123).put().accept("text/plain").post().execute();
Anyway, seems to me that we are on the same page in the most important aspects of the API. Let me finish my changes so
that I can push the latest version to the public repo.
Can I take your samples code and rewrite it to fit my version to have a better way to compare and pick the best of the
two worlds?
Marek
On 05/21/2011 05:34 AM, Bill Burke wrote:
> I put together an alternative client API to:
>
> * Simplify things
> * Expand interceptor model
> * Have interceptor model work in an asynchronous environment
> * Start work on server-side interceptor model
> * rework asynchronous callback model
>
> https://github.com/patriot1burke/redhat-jaxrs-2.0-proposals
>
> Examples:
>
> https://github.com/patriot1burke/redhat-jaxrs-2.0-proposals/tree/master/src/jax-rs-api/src/main/java/javax/ws/rs/client/examples
>
>
> The examples contain basic, async, and a gzip encoding/decoding example, and a client cache example.
>
>
> There's 4 different types of interceptors in the proposal:
> * RequestHander - executed before a request is dispatched to HTTP engine
> * ResponseHandler - Executed after HTTP engine returns, but before entity unmarshall
> * ReaderInterceptor - wraps around MessageBodyReader
> * WriterInterceptor - wraps around MessageBodyWriter
>
> Execution order looks like this:
>
> 1. RequestHandler's executed. If a ClientResponse is returned by any of these, use that response, and don't go remote.
>
> 2. Execute HTTP remotely. If there are WriterInterceptors, wrap them around call to MessageBodyWriter
>
> 3. ResponseHandler's executed.
>
> 4. ClientResponse.getEntity() invoked. If there are ReaderInterceptors wrap them around call to MessageBodyReader
>
>
>
> Steps 1, 2, 3, and 4 can all be executed in different threads if the runtime desires since I've split interception into
> request/response/readers/writers.
>
>