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