Hi
Please see comments with S.B
>
>
>> - the API was suddenly not consistent at all; following completely broken flow would be suddenly possible:
>>
>> invocation.method("PUT").entity(e).get();
>>
>
> "Completely broken" is a very large exaggeration. While possible, the possibility of anybody ever doing that is not
> very probable. Also, when you think about it, this isn't broken at all as its not much different than calling type()
> twice. What else was "completely broken", just this?
In anticipation of your reaction, I wouldn't dare adding extra interface to shield the type from overriding. :)
I was considering moving it to the invocation method, but it would produce too long method signatures. Admittedly it is
a trade-off. If you want me to fix it, I'll add one more builder IF.
S.B. I'd agree here that
> invocation.method("PUT").entity(e).get();
is not something API should allow...It will work but the line looks messy, not broken (at least I can support Bill on this one :-)), but messy...
> Finally, this doesn't look very "fluent" with the current API as the type and the entity are completely disjointed:
>
> target.type("application/xml").build("PATCH", customer).invoke()
As I said, we can either add the type to the invocation method or introduce an extra builder interface. Either way, we
would improve the consistency instead of loosing it.
>
> This is much more clear and easier to read (with the previous revision);
>
> target.request().type("application/xml").entity(customer).method("PATCH").invoke();
S.B. I like neither
> target.type("application/xml").build("PATCH", customer).invoke()
nor
> target.request().type("application/xml").entity(customer).method("PATCH").invoke();
I think users will avoid both options, when possible, though appreciate that perhaps in some cases this would be needed.
But I'm happy the current revision allows for much shorter expressions which
can express the same...
Thanks, Sergey
P.S apologies for stripping most of other content, just wanted to comment on the above two aspects