> 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
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>