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

[jsr339-experts] Re: HEADS-UP: Decide on fluent client API atributes: simplicity vs. consistency

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Fri, 26 Aug 2011 17:30:47 +0200

On 08/26/2011 04:45 PM, Bill Burke wrote:
> request().invoke() is an inconsistency, I'll give you that. But, request().header(...).method(...).header(...) is not
> an inconsistency. The fact that you don't like it is just a matter of personal taste.

I never said that request().header(...).method(...).header(...) is inconsistency. I am ok with it.

I was objecting to

request().header(...).method("PUT").header(...).get();

which just reads weird. And I am not alone. While my reasons for not liking this are different, today I got a feedback
from an observig user, that it's not clear if such invocation chain means "get the result of the previous put request"
or if it means something else.

> One last try:
>
> You could redefine the problem a bit. Remove the ability to change the method name in the request. Remove the ability
> to do invoke()/submit() style invocations. Its really questionable whether *real* users want these features anyways as
> they were both suggested, IIRC, by one of us guessing users would want those features.
>
> If you remove both of those, you get both a design-that-Bill-thinks-is-simpler and an
> API-that-Marek-thinks-is-purely-fluent.
>
> https://github.com/patriot1burke/redhat-jaxrs-2.0-proposals-rev2/tree/master/jax-rs-api-r3/src/main/java/javax/ws/rs
>
>
> I removed HttpRequest.method(String). invoke()/submit() methods now take a methodName parameter so that you can make a
> non-standard HTTP method invocation. (It made sense to use those method names instance of method()).

Incidentally, I just sent out my own proposal - have a look at the separate email accompanying it. I tried to accept all
reasonable simplifications you proposed so far. Many thanks for those. I am also explaining my reasons for not accepting
some of the changes.

The resulting API is simpler in the class and inheritance hierarchy. It is also much more consistently fluent while
allowing for the flexibility of working with HttpRequest directly. It is not the absolutely simplest, not 100%
consistent and leaks the lower layer API (by exposing HttpRequest) in certain flows. But it still reads well(IMO), is
easy to understand (IMO) and use (IMO).

Marek