What's the Best Way to Design a "Platform-Independent" GWT Server?

Question

What's the best way to design a Java server architecture that interacts with a client-side GWT application, but also responds correctly to various other client-requests from other platforms? Specifically, I'd like to use the same servlet layer to respond to not only my GWT application, but to corresponding iOS and Android applications.

The first approach I thought of would be to implement the GWT client layer using "RequestBuilder" rather than the usual RPC method service interfaces. Using this approach, I could code generic servlets that respond to HTTP requests in a RESTful manner by processing variables encoded in something like JSON or XML. Although this would work, it would be somewhat labor-intensive to have to encode and decode my objects/parameters in JSON on both the client and server, especially when RPC provided such an elegant solution.

The other approach (which I think is better), would be to find out the specification Google uses to serialize and deserialize their RPC method calls and implement some sort of library that does the same thing for iOS (in Objective-C) and Android. The problem is that I haven't been able to find good documentation about this encoding standard, nor have I found libraries that implement it for iOS or Android (although I did find something like it for PHP at www.gwtphp.com).

Could anybody steer me toward a specification for how GWT serializes/deserializes their objects or, even better, libraries for iOS and/or Android that implement RPC interfaces?

Answer 1

Make a "service" layer, i.e. a set of business classes that return POJOs.

Then you can easily have GWT-RPC and REST calling the service layer.

This is pretty easy and straightforward. Your issue is going to be how to create a business layer that only returns POJOs. But that's another story.

Answer 2

If you are truly trying to have a platform-independent server that clients can interact with, then your best bet is going to be to use a "least common denominator" approach, which is often simple data passing and surfacing handles for various actions to occur.

To that end, a RESTful interface, likely with either JSON or XML for encoding the data, is going to be your most supported bet.

The main advantage of going this way is that there are already lots of libraries that deal with serializing / deserializing JSON and XML, and you are keeping your service as flexible as possible, which means that you are not limiting your client base by requiring them to do very much other than deal with text and make web requests (at the most basic level).

It does put a bit more work on making the server-side of the connection do what you want, but that's the trade-off between the flexibility of fairly generic REST that any client can deal with and a much more target RPC-based service that, while it makes some implementations easier, does limit the clients to those that can deal with the specific RPC implementation.