Should I build a REST backend for GWT application

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?

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.

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](

[To see links please register here]

)) 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.

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][1]), 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.

[1]:

[To see links please register here]

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.

You can do both if use also use the [RestyGWT][1] 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.


[1]:

[To see links please register here]

We ran into the same issue when we created the <a href="http://www.spiffyui.org">Spiffy UI Framework</a>. We chose REST and I would never go back. I'd even say GWT-RPC is a <a href="http://www.zackgrossbart.com/hackito/antiptrn-gwt2/">GWT Anti-pattern</a>.

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.

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 (

[To see links please register here]

) - 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](

[To see links please register here]

). The switch was fairly painless and my POJO's serialize without issue.