Just a few notes I made while reading the samples in the WIKI.
* As ResourceUri is not an URI but actually a factory for invocations, it might be better to stick with WebResource, or use a
name like Endpoint or InvocationFactory. All those names make clear the "active" aspect of the class, while with ResourceUri
everybody might be surprised that it is a factory actually.
* While I understand that technically ".perpareX()" is the correct method name, I assume that end users might like to use the
simpler ".x()" instead (without "prepare"), as it is just so much shorter and better to read.
* What WebDAV people expect to see with regards to extensibility is not only ResourceUri.prepareMethod("COPY") but actually
ResourceUri.prepareCopy(). To be able to do that, obviously there must be a pluggable factory for ResourceUri subclasses to be
registered with Client, or Client itself must be WebDAVClient at runtime using some kind of WebDAVClientFactory. In the class
diagram I see that factories are planned, but it is not told how they get enabled. What would be the JAX RS 2.0 way to enable
a different factory to use WebDAV instead of simple HTTP? Note that I do not want to replace the JAX RS implementation but
just want to add WebDAV methods to be processed by the current implementation.
* I do not see what the befit of asynchronous client API should be compared to a simple Executor used within the client
application itself (besides two or three lines of less code in the complete client application which might be millions of code
long)? Will the specification define clear aspects what the Client implementation must fulfil ontop of a simple Executor or
will it be such vague as it currently is? I expect this to be defined clearly, as this was one criteria against the caching
proposal and we should balance the criteria detail of all features.
* From the view of the end user it is a bit verbose to write Client.create().request(). It would be very much more comfortable
to just write Client.request(), since obviously a create() will use a default config anyways, so this could be implied by a
direct Client.request() call. Only programmers wanting to share Client instances or wanting to use custom configs would have
to write Client.create() then (which will be the minority I assume and such support CoC).
* The filter example says a possible use of FilterAction.STOP could be a caching filter. Such a filter might need to not only
stop the filter chain, but replace the actual uncoditional call by a conditional one. In what way could the filter API solve
this?
* The interceptor sample says a possible use of interceptors would be GZIP. As GZIP is a transparent but essential part of
HTTP, I doubt that end users will understand that they must user interceptors to add GZIP. I think most would just expect that
GZIP is handled transparently by the JAX RS engine or it's transport delegate. I do not think that people would love to see
that they must handle GZIP again and again in every application they write. So the GZIP Interceptor should be a mandatory part
of any JAX RS implementation.
* The complexity of the current annotation based proposal for filters feels a bit overcomplicated. I am a big friend of annotations, aspects and all that, but it just so much simpler to write "Client.from(URL).filter(myFilter).post(entity)" than doing it the proposed way.
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Freitag, 3. Juni 2011 15:48
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Updated Client API and Interceptors/Filters
> proposal is available - please review
>
> Hello Experts,
>
> After a short pause, I am turning to you with a request to review our
> recent work. Please, review the updated proposals
> that were made available today:
>
> - Low-level Client API:
>
> The updated proposal page contains the accompanying text for the
> proposal. Please, use it as the introduction:
> http://java.net/projects/jax-rs-spec/pages/Low-levelClientAPI
>
> - Interceptors and Filters:
> The updated proposal is available here:
> http://java.net/projects/jax-rs-spec/pages/InterceptorsAndFilters
>
>
> Both proposals are accompanied by the source code. To get the sources,
> you can clone or push the content of the project
> git repository as described here:
>
> http://java.net/projects/jax-rs-spec/sources
>
> Once you have a local copy of the repository, the JAX-RS API sources
> are located under
>
> <local-repo>/src/jax-rs-api/src/main/java/
>
> Inspired by examples in Bill's Client API proposal, we have created
> additional maven project to host the JAX-RS API
> examples. This project including the proposed API examples can be found
> here:
>
> <local-repo>/src/examples
>
> (Note that some of the client-side interceptor/filter examples do not
> compile yet. This will be fixed soon.)
>
> Please familiarize yourselves with the proposal and provide your
> feedback.
>
> Thank you,
> Marek
>
> P.S. I am taking a vacation until the next Thursday (June 9). Santiago
> will be handling all the communication until I'm
> back.