Hi Marek
On 29/08/11 17:04, Marek Potociar wrote:
> 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.
Would you consider allowing for
> client.target(uri).request(contentType, accepted/type1,
accepted/type2, ...)
?
(cases involving multiple accepts can be addressed via request())
so that another typical case involving post can be addressed ?
client.target(uri).request(contentType, accepted/type1, accepted/type2,
...).get()
is possible which is not very cool - but one can do the same with
request() too.
having options for
client.target(uri).request(contentType, accepted/type1).post(entity)
and
client.target(uri).request(accepted/type).get()
is appealing to me
Sergey
>
> 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 :-)