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:20:54 +0200

Because a user might like to configure *all* requests upon a resource
without the need to repeat that with each invocation. If you use the URL
class, you cannot do that, since the URL class is not configurable.

> -----Original Message-----
> From: guilherme.silveira_at_gmail.com
> [mailto:guilherme.silveira_at_gmail.com] On Behalf Of Guilherme Silveira
> Sent: Dienstag, 5. Juli 2011 20:15
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
>
> > A resource is something that you can point to using a URL.
> So I really didnt get why the three interfaces dont solve the problem
> as the code I posted.
>
> Regards
>
> >
> >> -----Original Message-----
> >> From: guilherme.silveira_at_gmail.com
> >> [mailto:guilherme.silveira_at_gmail.com] On Behalf Of Guilherme
> Silveira
> >> Sent: Sonntag, 3. Juli 2011 15:31
> >> To: jsr339-experts
> >> Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
> >>
> >> > One might want to apply different sets of features (like
> filtering,
> >> caching,
> >> > etc.) to one resource.
> >> It seems I didn't quite understand what is being called a "resource"
> >> here. Is it something like:
> >>
> >> Client client = provider.create();
> >> Request r = client.at(uri);
> >> Request first = r.with(filterA()); // this one will only use filterA
> >> Request second = r.with(filterB()); // this one will only use filter
> B
> >>
> >> ?
> >>
> >> Regards
> >>
> >> Guilherme Silveira
> >> Caelum | Ensino e Inovação
> >> http://www.caelum.com.br/
> >>
> >>
> >>
> >> On Sun, Jul 3, 2011 at 10:24 AM, Markus KARG
> <markus_at_headcrashing.eu>
> >> wrote:
> >> > 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
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >