Hi,
On a general point: I would be interested in hearing more feedback
from other Jersey users f they would like proxy support or if they are
happy with the Jersey client API as is.
On Sep 3, 2009, at 2:46 PM, gerard davison wrote:
>
> Paul,
>
> I can understand the desire for loose coupling; but from a tools
> developer perspective almost the first thing people ask for is the
> ability to generate some kind of static java interface for a given
> WADL.
Old habits die hard :-)
> I can see the argument against it; but in many cases your "basic
> work-a-day" developer is not going to understand the finer
> distinctions in REST and wants a simple API to program against. This
> is the same thing we see with JAX-WS/WSDL where most user appear to
> treat it as a black box.
>
> Now with Jersey, as it currently stands, we can at least generate
> some JAXB files for the user if we expose the grammar using the WADL
> extension. I do wonder if this should be the default as it would
> make tooling much each to write. What is the reasoning behind not
> making this a default feature of the WADL generator?
>
Time and TLC in this area :-)
> As to the client interface, I guess this along with HATEOAS is
> something for JAX-RS 2.x, I do like how RESTEasy present these
> client interfaces:
>
> http://jboss.org/file-access/default/members/resteasy/freezone/docs/1.1.GA/userguide/html/RESTEasy_Client_Framework.html
>
> I am not saying this should be the only way to talk to a service;
> but it is certainly a nice model to present to developer who want
> something more concrete.
I avoided a proxy-based approach because JAX-RS artifacts do not
translate to the client side in all cases e.g. returning of Response
for example, or sub-resource locators. Which is why RESTEasy has to
deviate and have a class such as ClientResponse. I am not really
criticizing here just making an observation. RESTEasy is doing it's
best to work around the fact that JAX-RS 1.x was designed for server-
side only.
In general this approach can create the illusion that one can define a
set of interfaces that you implement on the server side and can reuse
on the client side. This approach can be limiting for a number reasons:
1) It makes it harder to implement the service. HTTP is the interface,
there is no need to define interfaces for your
resources unless it is required for some sort of internal
architectural detail.
2) If the client is also depending on those interfaces it may make it
harder to evolve the server side. With JAX-RS
it is possible to do all sorts of refactorings while from a HTTP
perspective the client will not notice anything,
in addition to adding more sub-resources or support for more
media types.
3) I get the impression that for a fully fleshed out client API to a
service a proxy-based approach or the builder
approach is not wholly sufficient and it is better to provide a
library. This is in fact what the Sun Cloud team
have done, using the Jersey API underneath to make it easier for
them to implement this API.
I can see the merit in some cases for a proxy-based approach if the
artifacts are independent from the server implementation and created
by the consumer or by the provider.
But, even then in terms of LOC you can achieve similar results using a
fluent-based API. And in terms of reuse i deliberately designed
WebResource to be reusable and for child resources to be easily
created, so you can be DRY.
I think the one clear advantage of a proxy-based approach is it can
act as a form of documentation in code and it makes it easier to write
code when using an IDE. (Fluent APIs are harder to document with
JavaDoc.)
Even though i am somewhat cold to lukewarm on the idea of proxies for
clients i suspect any JAX-RS 2.x effort will likely specify a solution
in addition to a fluent-based API.
What i would really like to see is the following tooling: having docs
and code completion with the Jersey client API based on dynamic
analysis of WADL obtained from the service. It could even provide
snippets of template Jersey client code that one could copy and paste.
The nice thing about this is it will work with any service that
provides WADL (e.g. Zembly uses WADL a lot for consuming services and
that WADL could be reused).
Paul.
> It is also something we can easily give the users to get them going.
> I have looked at the wadl2java project; but would prefer from a
> simplicity point of view to be able to point users at some part of
> the Jersey project.
>
> Cheers,
>
> Gerard
>
>
> On 19:59, Paul Sandoz wrote:
>> <div class="moz-text-flowed" style="font-family: -moz-fixed">On Sep
>> 2, 2009, at 9:31 AM, xworker wrote:
>>>
>>> Hi
>>>
>>> I'm using Jersery for ws in my project. I've got a JPA backend
>>> with lots of
>>> entitys. Question:
>>>
>>> How do I generate java POJO stubs from my Jersey ws? For SOAP I
>>> was able to
>>> generate client-side stubs, but not for REST?
>>
>> I advise against creating Java client stubs from Java server
>> artifacts because they make a tight coupling between client and
>> server-side code (but see later).
>>
>>
>>>
>>> Frontend is a backingbean with JSF pages.
>>>
>>> <code>
>>> wr =
>>> client.resource("http://localhost:8080/pe-backend/resources/activities
>>> ");
>>> activityList = wr.get(new GenericType<List<Activity>>() {
>>> });
>>> </code>
>>>
>>> How shouold my backingbean know what Activity is?
>>>
>>
>> Human readable documentation of the service to be read by the
>> developer. Because the client is separated from the server you can
>> also do:
>>
>> wr = client.resource("http://localhost:8080/pe-backend/resources/activities
>> ");
>> activityArray = wr.get(Activity[].class);
>>
>> or perhaps use a different version of Activity (JAXB is somewhat
>> flexible in terms of consuming documents with additional XML it
>> does not understand). Or use some XPath on DOM.
>>
>> WADL can be used to help create the human readable documentation
>> that can be served as part of the service. Jersey dynamically
>> creates a WADL description of the service, see also here:
>>
>> http://wikis.sun.com/display/Jersey/WADL
>>
>> If you really want static client stubs you could use the wadl2java
>> facility available from:
>>
>> https://wadl.dev.java.net/
>>
>> Paul.
>> </div>
>>
>
> --
> Gerard Davison | Senior Principal Software Engineer | +44 118 924 5095
> Oracle JDeveloper Web Service Tooling Development
> Oracle Corporation UK Ltd is a company incorporated in England &
> Wales.
> Company Reg. No. 1782505.
> Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.
>
> Blog http://kingsfleet.blogspot.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>