I'm not sure I understand what you mean by "proxy based approach" Do you
mean a set of richer classes in a client side "SDK" that proxies the real
HTTP calls?
On Thu, Sep 3, 2009 at 9:05 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> 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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>