Should I build a REST backend for GWT application

Question

I am planning a new application and have been experimenting with GWT as a possible frontend. The design question I am facing is this.

Should I use Option A: GWT-RPC and build the app quickly

Option B: Build a REST backend using Spring MVC 3.0 with all the great @Controller, @Service, @Repository annotations and build a client side library to talk to the backend using the GWT overlay features and the GWT Request builder?

I am interested in all the pros and cons and people experiences with this type of design?

Offertory

Some extra clarifications: 1) I might want to have other front ends for this application the keyword might so is there a design pattern to architect things with GWT-RPC in such a way that implementing a REST interface layer in the future does not require huge refactoring? – Offertory

Answer 1

Ask yourself the question: "Will I need to reuse the server-side interface with a non-GWT front-end?"

If the answer is "no, I'll just have a GWT client": You can use GWT-RPC, and take advantage of the fact that you can use your Java objects both on the server and the client-side. This can also make the communication a bit more efficient, at least when used with <inherits name="com.google.gwt.user.RemoteServiceObfuscateTypeNames" />, which shortens the type names to small numeric values. You'll also get the advantage of better error handling (using Exceptions), type safety, etc.

If the answer is "yes, I'll make my service accessible for multiple kinds of front-ends": You can use REST with JSON (or XML), which can also be understood by non-GWT clients. In addition to switching clients, this would also allow you to switch to a different server implementation (maybe non-Java) in the future more easily. The disadvantage is, that you'll probably have to write wrappers (JavaScript Overlay Types) or transformation code on the GWT client side to build nice Java objects from the JSON objects. You'll have to be especially careful when you deploy a new version of the service, which brings us back to the lack of type safety.

The third option of course would be to build both. I'd choose this option, if the public REST interface should be different from the GWT-RPC interface anyway - maybe providing just a subset of easy to use services.

Receive

Right now I don't need to build a separate REST interface but i might want to do so in the future. I don't believe in making things generic just because I might need it, I don't like paying for genric stuff upfront. Do you know any patterns that would allow me implement GWT-RPC to start such that adding a REST would be trivial on the same code base. – Offertory

@ams: Absolutely. You can probably introduce a mapper between Java and JSON objects as soon as you need it - and then you can actually choose between offering both services or deprecating the GWT-RPC. I wouldn't worry about anticipating generic Java Interfaces for this too much, because such a change will result in (small) code changes anyway. Just give yourself a reality check once in a while: "Where will this be hard to do in JSON later" (e.g. object graphs which reference the same instances multiple times - or which even contain circles - are easier to send with GWT-RPC). – Receive

Answer 2

You can do both if use also use the RestyGWT project. It will make calling REST based JSON resources as easy as using GWT-RPC. Plus you can typically reuse the same request response DTOs from the server side on the client side.

Adaline

Answer 3

We ran into the same issue when we created the Spiffy UI Framework. We chose REST and I would never go back. I'd even say GWT-RPC is a GWT Anti-pattern.

REST is a good idea even if you never intend to expose your REST endpoints. Creating a REST API will make your UI faster, your API better, and your entire application more maintainable.

Forestry

Answer 4

I would say build a REST backend. In my last project we started by developing using GWT-RPC for the first few months, we wanted fast bootstrapping. Later on, when we needed the REST API, it was so expensive to do the refactoring we ended up with two backend APIs (REST and RPC)

If you build a proper REST backend, and a deserialization infra on the client side (to transform the json\xml to GWT Java objects) then the benefit of the RPC is almost nothing.

Another sometimes forgotten advantage of the REST approach is that it's more natural to the browser running the client, RPC is a propitiatory protocol, where all the requests are using POST. You can benefit from client side caching when reading resources in the standard way.

Answering ams comments: Regarding the RPC protocol, last time I "sniffed" it using firebug it didn't look like json, so I don't know about that. Though, even if it is json based, it still uses only the HTTP POST method to communicate with the server, so my point here about caching is still valid, the browser won't cache POST requests.

Regarding the retrospective and what could have done better, writing the RPC service in a resource oriented architecture could lead later to easier porting to REST. remember that in REST one usually exposes resources with the basic CRUD operations, if you focus on that approach when writing the RPC service then you should be fine.

Gutenberg

From the google IO presentations the GWT-RPC protocol is JSON on the way back to the browser, and some other more efficient format on the way to the server, so I don't see the propitiatory nature of RPC protocol as an issue in deciding about REST vs. GWT-RPC. – Offertory

In Retrospect after you had to build these two backends did you see any way to build the GWT-RPC services in such a way that adding the REST back end would have been trivial? Can you share any lessons learned if you did want to have both GWT-RPC and REST – Offertory

Answer 5

The REST architectural style promotes inspectable messages (which aids debugging and security), API evolution, multiple platforms, simple interfaces, failure recovery, high scalability, and (optionally) extensible systems via code on demand. It trades per-interaction performance for overall network efficiency. It reduces the server's control over consistent application behavior.

The "RPC style" (as we speak of it in opposition to REST) promotes platform uniformity, interface variability, code generation (and thereby the ability to pretend the network doesn't exist, but see the Fallacies), and customized interactions. It trades overall network efficiency for high per-interaction performance. It increases the server's control over consistent application behavior.

If your application desires the former qualities, use the REST style. If it desires the latter, use the RPC style.

Nonnah

From the GWT-RPC things I have played with it really does not pretending that the network is not there, you have to explicitly write error handling code anytime you create Asyc client side implementation of a remote service interface. I get what you are saying regarding RPC vs. REST as an architectural choice. – Offertory

Answer 6

If you're planning on using using Hibernate/JPA on the server-side and sending the resulting POJO's with relational data in them to the client (ie. an Employee object with a collection of Phones), definitely go with the REST implementation.

I started my GWT project a month ago using GWT RPC. All was well until I tried to serialize an object from the underlying db with a One-To-Many relationship in it. And got the dreaded:

com.google.gwt.user.client.rpc.SerializationException: Type 'org.hibernate.collection.PersistentList' was not included in the set of types which can be serialized by this SerializationPolicy

If you encounter this and want to stay with GWT RPC you will have to use something like:

• GWT Request Factory (www.gwtproject.org/doc/latest/DevGuideRequestFactory.html) - which forces you to write 3+ classes/interfaces per POJO you want to share with the client. OUCH!
• Gilead (sourceforge.net/projects/gilead/) - which appears to a dead project.

I'm now using RestyGWT. The switch was fairly painless and my POJO's serialize without issue.

Anastos

Answer 7

I would say that this depends on the scope of your total application. If your backend should be used by other clients, needs to be extendable etc. then create a separate module using REST. If the backend is to be used by only this client, then go for the GWT-RPC solution.

Switcheroo