On Wed, Aug 28, 2013 at 6:04 AM, Thomas Broyer <[email protected]> wrote:
> Did I say that?! I see Retrofit as client-only (which I believe it is). > That said, I don't think you necessarily want the server-side to be > synchronous (it could actually be handy to be asynchronous) > Many of the annotations in JAX-RS really only make sense on the server. For example, annotating a parameter with @CookieParam makes little sense on the client. Sure, you could have it set the cookie prior to making the call, but presumably you are using @CookieParam because it is a persistent cookie across calls. @DefaultValue doesn't make any sense on the client, since you have the parameter in the interface so it must be supplied. > > >> So, I don't see a lot of benefit of being able to use the same interface >> on the client and server because you don't actually want that. We could >> certainly have a GWT-RPC-like generator that works with an arbitrary REST >> API using sync and async interfaces, and we could keep the GWT-specific >> bits out of the sync interface so that code could easily be "shared" (even >> though the generator would just verify that they are compatible). >> > > The problem with not sharing any code is that you have 2 things (at least) > to update and maintain in sync. When one can be generated from the other, > or both can be generated from a definition in whatever format (e.g. > Protocol Buffer), then that's not a problem though. > The problem with GWT-RPC is that we don't have anything to generate the > async interface form the sync one (the gwt-maven-plugin has some –broken– > support, as does the Google Plugin for Eclipse, and possibly the GWT > support in IntelliJ and/or NetBeans; but an annotation processor would Just > Work™ –OK, most of the time, it kind of sucks in Eclipse– and would work > everywhere). > I think this could work (you might have an issue figuring out void vs Request returns though). Personally, I don't find writing an Async interface that painful, and I would rather generate it once if I were going to rather than run APT. If you are using protos, you already have a codegen step to deal with anyway. > gwt-jsonrpc IMO adopted the most sensible approach without need of a > generator: async-everywhere (on the server-side, you don't return the > response, instead you give it to the callback; I believe this has to happen > synchronously though). > I still don't think you want the exact same interface on the client and server - for example, @CookieParams and @DefaultValue as mentioned above. There's also no reason to replicate all those annotations on the client interface -- just referencing the server interface should be enough if it exists (you could probably support arbitrary JAX-RS-like annotations, just matching the annotations without regard to their package). If I am just writing the client side to a third-party REST API, I would rather just write the client-side interface and be done with it, rather than writing the server interface and generating the client. Finally, if you only have one server implementation, having to write an interface for it seems a waste anyway -- just write the server class directly with its annotations, and write a separate async interface for clients (which could be generated). If the client doesn't have something GWT-specific in it, it becomes hard to trigger the right GWT generator for it. You could always make a useless subinterface that inherits from a marker interface to get that, but it is a pain. -- John A. Tamplin -- 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.
