What is the purpose of deploying REST when GWT-RPC suffices? Why REST with GWT?
There is an oft cited motivation for doing REST.
- so that you could reimplement your client using Fortran, Cobol, PHP, Python, other whatnots.
- OTH, so that you could reimplement your server using the above stated whatnots.
Honestly, those are insufficient excuses to do REST with GWT. The purpose of having a door on your house is not "so that I could have many locks on the door". Being able to have many locks is not the direct motivation, but is simply an enabler. Therefore, the above reasons combined with the following reasons complete the motivation why you should deploy REST instead of GWT-RPC or XML-RPC or SOAP.
- Scalability = Mashup-ability - multi-providers, multi war, application mash-up scenarios.
- Scalability - loose coupling between client and server.
- Visibility = Debugability - knowing exactly the data formats and schemata that are passed between client and server.
- Standards = Visibility - I have no idea how to decode the transported data in GWT-RPC; however, JAX-RS allows you to employ established standards of JSON and XML object schemata - namely, Jackson JSON and JAX-B XML have become popular modes of object schemata.
- Flexibility and Simplicity = Plugin-ability - loose coupling and visibility promote ease of development, enhancement and maintenance.
- Flexibility and Simplicity does ensure that your application can be reimplemented in a more capable future language that would one day replace Java's popularity as a business enterprise language - just as Java had replaced Cobol. It's good to plan in advance for future contingencies - but having many locks is not the motivation for having a door.
- Diversity and MVP-friendly - you could have a diversity of clients: Desktop heavy clients such as Swing, non-ASP .NET, Qt and light clients such as GWT, Qt. Qt is an interesting technology in that the same C++ code can be recompiled on Linux, Windows, and various mobile devices.
- Agile - Visibility, Simplicity and Flexibility allows rapid prototyping using scripts, Fiddler2 (or its FireFox equivalent), to be replaced by proper Java code when the DTO and SAPI hierarchies become more complex and entwined.
- Agile - allow a mishmash of services written mostly in Java but supplemented with script-based service providers.
- Simplicity, Diversity, Flexibility, Scalability, Mashup-ability = Agile and gradual technology renewal. When it is time to upgrade any part of your service framework, a RESTful implementation would allow you to do it piece-meal.
- Bookmarkability. This is the strongest motivation in many projects to use REST. When a bank sends you an email letting you reset your password, it is probably a URL link to a REST service. REST APIs are convenient as bookmarks and actions links. For example, your grandma does not know how to update her profile but she asks you to do it for her. Fortunately that particular web site operates on REST. So you crafted a URL and mailed/skyped it to her, telling her to click on the link after logging in to her account she wishes to update.
- RPC-ability. I don't think it is a hyperbole to say that many, if not most, RPC and XML-RPC proponents do not realise that REST can function as RPC. In fact, this series of posts focus on using REST as the RPC mechanism.
- XMLRPC-ability. Using the right framework, REST is XMLRPC+the advantages of REST.
- Terminologically SOAP - If you have used SOAP (Simple Object Access Protocol), you would agree that SOAP is a total misnomer because SOAP is not simple. Technically, REST is the actual simple object access protocol.
As long as your services or JEE server contexts reside within the same SLD-SOP restriction, REST would allow your GWT application to subscribe to multiple independently deployed server-side services. In fact, most enterprise GWT apps would need to subscribe to multiple independent services. For one, logging-in and user authentication should be a service of its own. Especially when you are using OAuth or OpenID.
You should see that GWT-RPC by itself is ill-equipped as a proper enterprise level enabler. GWT-RPC constrains you to only one service provider - the same service that serves the GWT UI itself has to serve the RPC service. Whereas REST would allow your GWT UI to communicate with another application context (i.e., deployed on a different war).
And then, if your service is on a different SLD origin, you could write a simple http proxy to forward-the-request/return-the-response, which invariably would run on its own war. In ancient terminology, a HTTP tunnel.
Continue next GWT with JAX-RS (aka RPC/REST) Part 1
You should see that GWT-RPC by itself is ill-equipped as a proper enterprise level enabler. GWT-RPC constrains you to only one service provider - the same service that serves the GWT UI itself has to serve the RPC service. Whereas REST would allow your GWT UI to communicate with another application context (i.e., deployed on a different war).
And then, if your service is on a different SLD origin, you could write a simple http proxy to forward-the-request/return-the-response, which invariably would run on its own war. In ancient terminology, a HTTP tunnel.
Continue next GWT with JAX-RS (aka RPC/REST) Part 1