On Wednesday, August 28, 2013 10:29:40 AM UTC+2, Jens wrote: > > > There was talk at the last GWT meetup of adding official JAX-RS support to >> GWT. There are several implementations floating around (RestyGWT, >> Errai-JAXRS, etc) Is this another JAXRS implementation? I'd be interested >> in seeing a comparison between the major implementations. >> > > I find the approach of flatpack-java from Perka interesting. What it > basically does is to provide a class named ApiDescription which gathers > information about a single resource and publishes that information through > a dedicated method on that resource, e.g. /people/describe. Then they > provide a code-gen tool that reads the JSON ApiDescription and generates > the client API. This code-gen tool is pluggable and currently its possible > to generate Java, JavaScript, Objective-C, Php and Ruby client APIs. There > was some work to provide a GWT code-gen dialect but not sure if it already > works. > > What I like about this approach is that you don't have to manually write > client APIs for various devices/languages and that you can easily add > additional languages to the code generation. That way you can easily > support various devices which is one of the main reasons why you would use > a server talking JSON. > > I think if GWT wants to support JAX-RS it should have the same flexibility > as the approach above (or GWT just maintains a GWT dialect for > flatpack-java). > > Project: https://github.com/perka/flatpack-java > Code-Gen Dialects: > https://github.com/perka/flatpack-java/tree/master/fast/src/main/java/com/getperka/flatpack/fast >
Isn't that what Cloud Endpoints do already? The problem with both of them is that you cannot write a client for any existing web API, as there are constraints in what you can do. Flatpack also comes with its own protocol (when Cloud Endpoints use JSON-RPC; why do you think there's a JSON-RPC dialect in RequestFactory ;-) ) Disclaimer: I haven't looked at flatpack for a while. I like what Square did with Retrofit http://square.github.io/retrofit/, which looks a lot like Errai's JAX-RS. The net advantage of Errai's JAX-RS is that you can simply implement your interface on the server-side and have the annotations inherited from it. AFAICT this is the same as Resteasy's proxy framework: http://docs.jboss.org/resteasy/docs/3.0.2.Final/userguide/html/RESTEasy_Client_Framework.html, so your client interface could be shared by your GWT client, Android client (or anything running in a JVM) and server resource (whether Resteasy or Jersey). Errai's approach to asynchronous calls feels like an ugly hack too: they absolutely wanted to be able to use the exact same interface everywhere, when an async interface could be automatically generated from the synchronous one (e.g. using annotation processors so it works in any IDE and outside IDEs too). Compare that, for example, to gwt-jsonrpc from Gerrit, where everything "looks" asynchronous (and the server-side could possibly be *made* asynchronous with servlets 3). The problem with all of them (Retrofit, JAX-RS, Errai) is how to configure them (almost everything in Errai shouts “unoptimizable output” though; Errai puts the focus on the developer's productivity when GWT is about optimized JS), particularly how you configure such things like "interceptors" to inject headers or process error responses (e.g. to handle authentication; probably something similar to the RequestTransport of RequestFactory, or the RpcRequestBuilder of GWT-RPC) and marshallers/unmarshallers; and make that configuration "GWT friendly". Maybe we should wait for the GWT.create() changes. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
