Hi Sergey,
to do a typical GET request, which most likely will be the most prevailing use case, you SHOULD:
- specify URI,
- specify acceptable response media types
- specify method (GET)
With the current API proposal you can do:
client.target(uri).request(accepted/type1, accepted/type2, ...).get();
to me, it's as simple as it gets.
And what if one wants to send a HTTP GET without the accept headers? No implementation would object to:
client.target(uri).request().get();
But why the extra verbosity in this case? Well, IMHO, that's not what one SHOULD do. It is OK for the API to slightly
push you in th right direction. And it's also OK, if such use case is more verbose that it could be.
But what about the the (post)/put/delete? Admittedly, those do not necessarily need the extra request() and are somewhat
a victim of the design decision about the interface inheritance. But since those are expected to be used less often, I
guess an extra .request() is tolerable.
I have to confess that advocating any side in this particular case is difficult for me. I see the point in what Bill and
Santiago say about SoC and I see the practical side you and Markus are appealing to. I have opted for a compromise
solution that would make the most prevailing simple use cases (GET/POST) as simple as possible[*] while respecting the
SoC argument.
Marek
[*] assuming we are considering the correctly formed requests with the accept header present
On 08/29/2011 05:21 PM, Sergey Beryozkin wrote:
> On 29/08/11 16:12, Bill Burke wrote:
>>
>>
>> On 8/29/11 11:04 AM, Sergey Beryozkin wrote:
>>> Just few days ago you were all explaining to Bill how important it was
>>> to keep users happy
>>
>> Its funny because I've been trying to do the exact same thing: explain
>> how important it is to keep users happy. A API design that makes sense
>> and is self-documenting creates a lot of user happiness.
>>
> LOL :-)...
> I'd say as a user I want to see
>
> target.path(...).header(blah).get();
>
> get() *is* a request. Thus request().get() is a duplication. The transition may look better at the interface level - but
> no so at the user level (at least to me). The problem is request() is only there to address the case which most of users
> like me won't deal with.
>
> apologies if I sound like a broken record :-)