jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [ClientAPI] Naming Proposals

From: Markus KARG <markus_at_headcrashing.eu>
Date: Thu, 14 Jul 2011 19:15:36 +0200

Can you give a real-world scenario when something complex like that will be
needed?

> -----Original Message-----
> From: guilherme.silveira_at_gmail.com
> [mailto:guilherme.silveira_at_gmail.com] On Behalf Of Guilherme Silveira
> Sent: Mittwoch, 13. Juli 2011 14:24
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
>
> > I do not see a need for that.
> And if the client needs to set 3 config for N resources, but not for
> every resource, he will do:
>
> Resource 1st = ...
> Resource 2nd = ...
> ...
> Resource nth = ...
>
> config(1st, 2nd, ... nth);
>
> void config(List<Resource> rs) {
> for(Resource r:rs) {
> r.enableFeature(first);
> r.enableFeature(second);
> r.withHeaders...;
> }
> }
>
> Something like that?
>
> Regards
>
> Guilherme Silveira
> Caelum | Ensino e Inovação
> http://www.caelum.com.br/
>
>
>
> On Tue, Jul 12, 2011 at 2:57 PM, Markus KARG <markus_at_headcrashing.eu>
> wrote:
> > I do not see a need for that.
> >
> >> -----Original Message-----
> >> From: guilherme.silveira_at_gmail.com
> >> [mailto:guilherme.silveira_at_gmail.com] On Behalf Of Guilherme
> Silveira
> >> Sent: Dienstag, 12. Juli 2011 16:58
> >> To: jsr339-experts_at_jax-rs-spec.java.net
> >> Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
> >>
> >> Hi Markus,
> >>
> >> I got it now. A detached Invocation-alike instance support for
> >> Resource based mappings. Wouldn't it be better to make it more
> generic
> >> and support any kind of detached support then? i.e.:
> >>
> >> > ClientFactory f = ClientFactory.instance();
> >> > f.enableFeature(x);
> >>
> >> > Client client = ClientFactory.create()
> >> > c.enableFeature(y);
> >>
> >> > Invocation i = client.post();
> >> > i.enableFeature(z)
> >>
> >> > DetachedInvocation i = Prepare.from(URL);
> >> > i.enableFeature(z);
> >>
> >> > i.queue(r);
> >>
> >> where
> >>    DetachedInvocation := Invocation - execution methods
> >>
> >> So it gives support not only to Resource based warming up of
> objects,
> >> but anything like:
> >>
> >> zippingHeaders = Prepare.withHeaders(...)
> >> commonFeatures = Prepare.with(Feature1.class).with(Feature2.class)
> >>
> >> Invocation i = ClientFactory.create().get().post(); // the same as
> your
> >> code
> >>
> >> i.queue(zippingHeaders.with(commonFeatures));
> >>
> >> Regards
> >>
> >> Guilherme Silveira
> >> Caelum | Ensino e Inovação
> >> http://www.caelum.com.br/
> >>
> >>
> >>
> >> On Wed, Jul 6, 2011 at 4:22 PM, Markus KARG <markus_at_headcrashing.eu>
> >> wrote:
> >> > (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
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >