The problem is that three parts does not match all requested features:
One might want to apply different sets of features (like filtering, caching,
etc.) to one resource. This information is neither bound to the client
(unless you create one client per resource) nor to the request (unless you
set the configuration at every other request). So to support this, you need
the resource as the forth brick in this puzzle. Or you just will not support
that usage pattern and prevent the possibily to add it at any later time, as
the API cannot be changed anymore without breaking backwards compatibility.
Regards
Markus
> -----Original Message-----
> From: guilherme.silveira_at_gmail.com
> [mailto:guilherme.silveira_at_gmail.com] On Behalf Of Guilherme Silveira
> Sent: Sonntag, 3. Juli 2011 14:38
> To: jsr339-experts
> Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
>
> Hi Markus,
>
> I can see three distinct elements while requesting:
>
> :: Provider => Client => Request
>
> A provider provides a client that starts building a request. The
> request builts on top of itself until its dispatched. Finally, on the
> response:
>
> :: Response
>
> I believe this is the simplest I can get. Restfulie is similar:
> Provider = Restfulie
> Client = RestClient
> Request = Request
> Response = Response
>
> The final code can be any of (explosion of methods or no compile time
> check):
> Provider.create().at(uri).get()
>
> or caching objects, with invoke on its parent (apache commons alike,
> type safe one ntity body etc):
> client.invoke(preparedRequest)
>
> One can break the interface into smaller pieces and try to achieve
> better type compile time checking.
> I am ignoring the hypermedia part so far (for which I would add a Link
> and Form interface).
>
> Thisis the one I was going to propsoe,but it didnt seem interesting, is
> it?
>
> Regards
>
> Guilherme Silveira
> Caelum | Ensino e Inovação
> http://www.caelum.com.br/
>
>
>
> On Sat, Jul 2, 2011 at 4:56 AM, Markus KARG <markus_at_headcrashing.eu>
> wrote:
> > Experts,
> >
> >
> >
> > reading the very interesting recent discussion about the naming of
> the
> > client parts, I have to say that I share both opinions: The
> complexity is
> > needed to reach the intended feature set and flexibility, but the
> current
> > naming is far from being intuitive. Thus, I'd like to propose just
> names
> > (not any different implementation or "revolution"). Maybe picking
> some of
> > them can solve the problem. Maybe other experts have even better name
> > suggestions to solve the trouble?
> >
> >
> >
> > "Engine", "Implementation", "JAXRS" or "REST" -- The major entry
> point for
> > separating vendor specifics, providing Client. In fact, "Provider" is
> great
> > as it is used by JPA already, it is used already differently in JAX-
> RS.
> > "JAXRS" was inspired by "JAXB", which is a smart, static entry point.
> >
> >
> >
> > "Client" -- A configurable instance ready to access a web resource
> (provides
> > invocations).
> >
> >
> >
> > "Target" -- sorry but 'Link' is just confusing and "WebResource" was
> not
> > wanted. Also Link might be needed for Hypermedia API later in this
> project.
> >
> >
> >
> > "Invocation", "Call", "MethodExecution" -- Well, obvious.
> >
> >
> >
> > 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.
> >
> >
> >
> > Regards
> >
> > Markus
> >
> >