On 08/26/2011 06:29 PM, Sergey Beryozkin wrote:
> On 26/08/11 17:25, Marek Potociar wrote:
>>
>>
>> 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.
>
> Content-Type and Accept are two fundamental headers - having no explicit accept() is -1
There still is explicit accept(...), it's just not on the main fluent API flow anymore, since it's functionality is
covered by request(...).
Marek
>
> Sergey
>
>>
>> Marek
>>
>>>
>>>> In the fluent interface I prefer async().put() over putAsync() or
>>>> asyncPut().
>>>
>>> Me, too.
>>>
>>> Regards
>>>
>>>
>
>