> > 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. >
Sure its very similar to Cloud Endpoints. What kind of protocol is used is kind of irrelevant. First we need to figure out whats the most easy yet flexible approach to support JAX-RS. If the final solution is designed well it shouldn't be a problem to make the actual protocol pluggable. 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. > Don't forget iOS. Everything mentioned above are Java/JVM based solutions that won't work on iOS. Cloud Endpoints also provides a generator for native Objective-C client Api. https://developers.google.com/appengine/docs/java/endpoints/consume_ios There are basically two kinds of situations to support: 1.) As a company you have a REST/JSON server and want to consume the data in various devices in various languages. Everything is under the control of the company. The generator (flatpack, Cloud Endpoints) approach would work well here. And if the company opens its API for 3rd parties, these 3rd parties could also use the generator approach because an API description is available that the generator understands. 2.) You want to consume an existing web API that may or may not have a machine readable API description. In case of 2.) if a machine readable API description is available we could make a generator to understand it (probably in a pluggable way). If only a API documentation exists (web pages) then a generator can not really help unless the developer is willing to write a machine readable API description based on the API documentation. IMHO if GWT provides REST support it should support 1.) and 2.) and not just 2.). -- J. -- 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.
