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

[jsr339-experts] Re: FWIW

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Fri, 26 Aug 2011 18:25:34 +0200

On 08/26/2011 06:19 PM, Markus KARG wrote:
>> Markus, Sergey: I have reintroduced the target.request(), you didn't
>> like. However I tried to do it in a way that does
>> not bring any extra method into the invocation chain. Instead of:
>>
>> client.target().accept("text/plain").get();
>>
>> You can now write:
>>
>> client.target().request("text/plain").get();
>
> Actually I do not see why it is necessary to *rename* the method. Obviously it still is used to pass in the accept header, so why not still name it accept, independent of what it actually does or produce?

It was not just a pure rename... This method provides the cleaner shift in the flow context and does not require Target
to implement headers builder interface. I know accept() does not require implementation of any interface either, as
such. But once we have accept(), why don't we have header(), allows() and other header-related mutators? And then we're
back to the SoC issue pointed out by Bill and Santiago.

Marek

>
>> In the fluent interface I prefer async().put() over putAsync() or
>> asyncPut().
>
> Me, too.
>
> Regards
>
>