(using fancy method names, not aligned with any proposal)
ClientFactory f = ClientFactory.instance();
f.enableFeature(x); // enables feature x for all clients to prevent
repeating
Client client = ClientFactory.create()
c.enableFeature(y); // enables feature y for this client only, other clients
must not have this enabled.
Invocation i = client.post();
i.setHeader(...);
Resource r = Resource.from(URL);
r.enableLogging(); // all access to this resource must be logged, but not
other resources
i.queue(r);
If you do it with less interfaces, you would enable logging on other
resources, too, or you have to repeat the logging enablement with all
resources (creates log clutter), or you would enable feature y on all
clients (even if not wanted there, especially in server side client API
usage where another client is needed for a different application), or you
would have to repeat enableFeature(x) for all clients.
So, how you like to solve that?
Regards
Markus
> -----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:41
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
>
> > 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.
> I still can't see why he wouldn't be able to do that with 3
> interfaces, can you show me the code that is possible within the
> current approach? And I try to write with three interfaces?
>
> Regards
>
> Guilherme Silveira
> Caelum | Ensino e Inovação
> http://www.caelum.com.br/
>
>
>
> On Tue, Jul 5, 2011 at 3:20 PM, Markus KARG <markus_at_headcrashing.eu>
> wrote:
> > 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
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >