JEP 110 - Violating Naming Convention ?

[Aaron Scott-Boddendijk]

I agree that using METHOD() is clever.  However I think it hides the fact
that you're building the request, not executing it. Similarly the
".response()" on HttpRequest itself suggests you're just retrieving the
response but this is where the execution happens.

I would prefer the methods better describe what they're doing (verbs)...

HttpResponse response = HttpRequest
    .create(URI.create("..."))
    .asGET()
    .send();

Still breaking the naming convention to clearly express the standard
recognised HTTP method names but more clearly as setting an attribute.
Then indicating where we're actually sending the request (HttpResponse
being the method-call result, something everyone is familiar with).

Then this makes more sense...

HttpRequest request = HttpRequest
    .create(URI.create("..."))
    .asGET();

--
Aaron Scott-Boddendijk

On Thu, Aug 18, 2016 at 3:02 AM, Mario Torre <neugens at redhat.com> wrote:

> On Wed, Aug 17, 2016 at 4:50 PM, Andrew Haley <aph at redhat.com> wrote:
> > On 17/08/16 14:51, Rahman USTA wrote:
> >> Thank you Pavel, this uncommon usage looks to me very weird.
> >>
> >> I hope it could be re-evaluated again.
> >
> > I don't agree.  If you look at RFC 2616 you will see that the HTTP
> > Method is called GET.  All in capitals.  In all documentation it is
> > called GET.  To call it, say, "get" would be the odd thing to do.
> >
> > Andrew.
>
> Indeed, it looks more clear this way. If you see POST and the likes
> follow the same idea.
>
> If you think about that, you don't really "get" something as in the
> general concept of java use of "get", what this method does is to
> create a GET request (or similar a POST one).
>
> In my opinion is a clever way to highlight the API is not the usual
> get/set styled bean.
>
> Cheers,
> Mario
>