jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [ClientAPI] Naming Proposals

From: Markus KARG <markus_at_headcrashing.eu>
Date: Tue, 5 Jul 2011 20:03:46 +0200

> On 7/2/11 3:56 AM, Markus KARG wrote:
> > "Target" -- sorry but 'Link' is just confusing and "WebResource" was
> not
> > wanted. Also Link might be needed for Hypermedia API later in this
> project.
> When you start creating a Hypermedia API, you'll find you want to
> create
> requests from a Link, so I don't see what's wrong with the "Link" name.

A "Link" is relation from one "Resource" (the "Source") to another (the
"Target"), and such has an assigned relationship role. It's just like edges
between nodes in graphs. "Link" is an edge, "Resource" is a node. We should
not mix it, since one can do different things with edges and nodes.

> IMO, Keep it, and figure out later on if it needs to be changed.
>
> > "Invocation", "Call", "MethodExecution" -- Well, obvious.
> >
>
> I like the current hierarchy of HttpRequest->Invocation.

I also like "Invocation", I just wanted to explain why we need that name,
since there was objection against that entity in this forum.

> > I think everybody agrees that the separation is needed, so the
> current
> > dispute should be easy to solve if more experts share their ideas
> about
> > the naming.
> >
> > About invoke() I understand that it is not smart to need
> get().invoke()
> > vs. get().queue(), but I do not see that
> invoke(invocationFactory.get())
> > or queue(invocationFactory.get()) would be any better - but less
> fluent.
> >
>
> Didn't we originally have:
>
> Response = invocation.get();
> Future = invocatoin.getAsync();

To support the extensibility needed for WebDAV, this would enforce a
mechanism to extend the invocation factory to deliver WebDAV invocations (so
we can write invocation.propfindAsync() then, too). Do we have such a
facility?

> Maybe have
>
> AsyncInvocation a = client.async();
> Invocation i = client.invocation();

If we do that, how to make WebDAV work? It would assume that client is able
to do WebDAV, so the factory for Client must not be jax-rs vendor dependent
then, but purely configurable by the application provider.

> Future f = a.get();
> Future f = a.post();
>
> String enttity = i.get(String.class);
>
> Remove the invoke() and queue() methods. This way get, post, et. al.
> is
> always invoked last to trigger the actual invocation.

Having invoke(Method) and queue(Method) allows to provide custom methods
like WebDAV. I do not see an easy solution for that without invoke() and
queue().

Regards
Markus