GWT Rich Internet Application (RIA) and REST HATEOAS - how compatible are they?

Question

I am in the process of developing a rich internet web application that communicates to a (Java) back-end via web services. I have prototyped a user interface in both Flex/Flash and GWT/Javascript and have noticed that these RIA platforms tend to favor an RPC-style method of back-end communication (AMF for Flex and GWT-RPC for GWT).

In my case, the server also needs to provide web services other clients that I do not author. Because of this, I am leaning towards standards-based web services (e.g. SOAP and REST). I am convinced that the RIA must use the same web service we provide for others. I "get" SOAP because it models the RPC style I am familiar with from experience. I am new to REST, but have prototyped a REST back-end using CXF/Jackson. At this time, however, my REST API still feels like an RPC-style API and I realize it's because I am having trouble getting my head around the idea of HATEOAS.

I have read Roy T. Fieldings helpful blog post about 10 times and I think I am beginning to see the light. For example, it is clear to me that if I were to include links to various state transitions along with my resource I could really reduce the amount of coupling between my client and server. My client could just render buttons that provide the user with access to the legal operations that can be performed on the displayed entity at that time.

But does loose coupling between a RIA and its server application matter?

By their very nature, RIAs are pretty tightly coupled with the server data model. Out of the box they presuppose many things. I am guessing that is why they also prefer an RPC-style application protocol...because loose coupling is not a design goal. But I am beginning to realize that if we took HATEOAS seriously, we could write a much more generic RIA client that would make VERY few assumptions about the data model and operations that can be performed. That could reduce the amount of effort to maintain the client through changes in the back-end, but does this make sense? does the benefit outweigh the cost?

p.s. - Two more details -- This application has an extremely complex, deeply nested data model. Also, I could not care less if somebody tells me we are not a 100% pure REST web-app.

Answer 1

It's an excellent philosophical question. My general response is some coupling should be expected.

Let me explain more. While it's possible to conceive of a fully generic application interface that just exposes the model in a human-usable way, it's actually incredibly difficult to write such a piece of software except for truly miniscule domains (e.g., filling a record that will be used to populate a DB where all the fields are picked from finite simple enumerations). If your application doesn't fit that model, you're going to have to have something in there that is specific to the app. If you do that in a “generic” way, you'll be downloading a complex description of what your generic client app is supposed to do, and that description will itself start to feel more and more like a programming language. Now you're back to square one, except with a (probably badly-designed) new domain-specific language in the mix as well. You might as well cut to the chase and accept that going wholly generic isn't worthwhile.

But that's not to say that you shouldn't take care to think carefully about what resources you expose, what verbs apply to those operations, and how users' software will discover those resources. Following REST and HATEOAS there will help a lot (and it helps if you've got a clear idea about what the application's underlying abstract model is; you should aim to expose that in a natural way).

Answer 2

Given that the GWT app is served by HTTP, having it tightly coupled with the server is not violating HATEOAS. It's" code on demand".

Google, Twitter and Facebook all use specific APIs for their app, different from the one exposed to third parties (Twitter has recently moved to using their public API for their web app, but it wasn't originally the case). Google said they had no plan to move G+ over to its public API, because it allows them to experiment and make breaking changes without breaking third parties.