I've combined comments from Sergey and Marek
On 8/24/11 6:11 AM, Sergey Beryozkin wrote:
S.B. I'd agree here that
>> invocation.method("PUT").entity(e).get();
> is not something API should allow...It will work but the line looks
messy, not broken (at least I can support Bill on this one :-)), but
messy...
>
It's funny we're arguing over something that will *very rarely* be used.
If we added a patch() method, the probability of somebody using that
method would probably converge to 0%.
On 8/24/11 5:21 AM, Marek Potociar wrote:
>> No, I don't see it. Especially when you only gave one example of its deficiency. And even that deficiency was debatable.
>>
> I reiterated multiple times over the consistency issue. I tried to explain why it is a fundamental problem when it comes
> to the fluent API. I am done repeating myself. Take it or leave it, it's your choice.
>
Seriously Marek, WTF? You've "reiterated" about how inconsistent the
previous proposal was without giving any real specific details other
than the trivial, debatable method() one. Leaving me only to guess.
The only thing I could find was this:
"...the proposed flow is
this - bootstrap client, specify path, set headers, (invoke method [with
content] | build invocation command [with
content]). Each part of this DSL requires it's own context
representation. That's where the extra interfaces come from."
The previous proposal, combined with the suggestions I made[1] and
linked to give you this exact proposed flow, albeit with the method()
inconsistency (which really isn't a inconsistency, as the method()
method is part of building the request).
Maybe you're trying to say that this is also inconsistent?
client.request().type("application/xml").pathParam("id",
123).queryParam("foo", "bar").entity().put()
WHich was allowed with the previous proposal. Removing pathParam,
queryParam, et. al. from HttpRequest would solve this problem. It would
separate URL building from request building.
So, I think the previous proposal+bill[1] could be salvaged and greatly
simplify the hierarchy if:
* you add a request() method to Target
* You remove pathParam(), queryParam(), et. al. from HttpRequest
* You combine AsyncInvocation and Invocation so that asynchronous
decisions can be made at the end i.e.
interface Invocation {
HttpRequest put(...)
Future putAsync(...)
Future submit()
HttpRequest invoke()
}
IMO, a MediaType should be added to put() and post() methods as this
will be the norm rather than the exception.
If I've been sounding angry, I am. IMO, we were starting to settle into
a simpler saner design that didn't compromise the goals of the
specification. The latest revision is a complete 180 of this. I am
convinced we can have both a simpler design with a consistent fluent API
with a little bit more effort.
BTW, if it all boils down to a "take it or leave it", I'd eventually
leave it and put a lot less effort into this specification. But I still
have energy and passion here to make this work.
Bill
[1]
https://github.com/patriot1burke/redhat-jaxrs-2.0-proposals-rev2
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com