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
>
>