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

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

From: Guilherme Silveira <guilherme.silveira_at_caelum.com.br>
Date: Sun, 3 Jul 2011 10:31:23 -0300

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