A resource is something that you can point to using a URL.
> -----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
> >> >
> >> >
> >
> >