On Fri, Sep 4, 2009 at 3:13 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> On Sep 3, 2009, at 4:53 PM, Andrew Ochsner wrote:
>
> 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?
>
>
> I mean something like the following interface:
>
> public interface ProxyResource {
> @Path("{id}")
> @GET
> String get(@PathParam("id") int id);
> }
>
> with:
>
> Client c = ...
> ProxyResource pr = c.proxy("http://localhost/xyz", ProxyResource.class);
> String s = pr.get(1);
>
> or:
>
> WebResource r = ...
> ProxyResource pr = c.proxy(ProxyResource.class);
> String s = pr.get(1);
>
> rather than:
>
> Client c = ...
> WebResource r = c.resource("http://localhost/xyz").path(1);
> String s = r.get(String.class);
>
> Paul.
>
>
Ah thank you. Makes sense now. I <personally> don't have a need or desire
for that. Agree that old habits die hard. It wasn't until I started
working with the Jersey client that I finally "got" REST. The proxy
approach feels too RPC. Which isn't to say it's bad or anything. It's just
not REST. Why not use SOAP/JAX-WS then? If what you're looking for is tool
support and/or statically generated clients, then I think SOAP style
services are a better choice. If that's your focus, do you really care what
goes over the wire?
And, also... agree that providing a library to clients ala Sun Cloud API is
a great approach and is what we do today. Writing that library is at least
as easy if not easier for our REST services using the Jersey Client API as
it exists today... as opposed to our libraries that talk to SOAP services.
I still don't think I've seen a good example of a real HATEOS type client.
Sounds like the holy grail ...but just out of reach.
> 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
>>
>>
>
>