Ho Sergey
I understand and it makes total sense. In a process you cant expect
everything to return what you wanted. Thats why navigatin through remote
proxied for rest also seem weird.
But is it somehow connected with the question in this thread?
regards
Guilherme Silveira
On Jul 20, 2011 10:46 AM, "Sergey Beryozkin" <sberyozkin_at_talend.com> wrote:
> Hi Guilherme,
>> Sure! My bad not to include any example. While writing the example (see
>> below), I realized that the once proposed "Link" type (with its factory)
>> would do it, if I am not wrong.
>>
>> Here is the example:
>>
>> Take any process that navigates through a set of URIs, as in a process
>> that is executed in 4 steps, and you want to execute the same process
>> for the 5 different entry points. For example: I want to query different
>> providers about some information. So:
>>
>> client = ...;
>> for(entry : entries) {
>> result = process1(entry, client.addHeadersForThisRequestA())
>> result = process2(result.link("a").addHeadersForThisRequestB())
>> result = process3(result.link("b").addHeadersForThisRequestC())
>> result = process4(result.link("c").addHeadersForThisRequestD())
>> result = process5(result.link("d").addHeadersForThisRequestE())
>> }
>>
>> Every step is based on a link. not an URI. So if the Link type as
>> proposed earlier provides the same configuration interface as Resource
>> (and the Client), it should be ok.
>>
>
> The above looks nice - but what happens if result.link("a") returns null ?
> I'm not trying to be negative here, just think the fluent style works
> nice when the builder state is under control, the above is conditional
> on the presence of "a", etc.
>
> Thanks, Sergey
>
>> Regards
>>
>> Guilherme Silveira
>> Caelum | Ensino e Inovação
>> http://www.caelum.com.br/
>>
>>
>> On Thu, Jul 14, 2011 at 2:15 PM, Markus KARG <markus_at_headcrashing.eu
>> <mailto:markus_at_headcrashing.eu>> wrote:
>>
>> 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>
>> > [mailto: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
>> <mailto: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 <mailto: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>
>> > >> [mailto: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
>> <mailto: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 <mailto: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>
>> > >> >> [mailto: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
>> <mailto: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 <mailto: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>
>> > >> >> >> [mailto: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
>> <mailto: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>
>> > >> >> >> >> [mailto: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 <http://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 <mailto: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>
>> > >> >> >> >> >> [mailto: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 <mailto: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
>> > >> >> >> >> >> >
>> > >> >> >> >> >> >
>> > >> >> >> >> >
>> > >> >> >> >> >
>> > >> >> >> >
>> > >> >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >
>> > >> >
>> > >
>> > >
>>
>>
>
>