On Wednesday, August 28, 2013 11:37:15 AM UTC+2, Jens wrote: > > 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. >
It depends what our goal is. If it's to support arbitrary REST endpoint (with marshalling, otherwise RequestBuilder or XMLHttpRequest would be enough), then we're protocol-agnostic besides HTTP. You could build protocols (RPC, RF, JSON-RPC) on top of it but if you're going to hide it then why not just use RequestBuilder or even XMLHttpRequest? > 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 > But all we need is a generator for GWT from Cloud Endpoints "discovery" descriptions (and it already exists AFAICT) > 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.). > There should be support for both, but not necessarily in GWT proper. I have no idea what the discussions at the pre-I/O meeting were, whether it's about "replacing GWT-RPC" (possibly being "more RESTful" and less "RPC", but handling marshalling) and/or having better support for REST (possibly with pluggable and/or flexible marshalling). -- 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.
