Google's Google Web Toolkit (GWT) has make remarkable breakthroughs in allowing Java developers to easily create websites and web-based applications with little concern about cross-browser issues. As a software developer fitting this niche, I must say I am more than happy with what GWT provides.
That said, one of the biggest complaints about GWT is it's Remote Procedure Calls (RPC). In a nutshell, your client calls a function through an interface which the server interprets, executes, and returns a Java representation of results. The actual process is somewhat annoying to implement, can be somewhat clunky, and can have the speed of the DMV lines at the end of the month. Ok, so I'm exaggerating a bit, but it's nuiances were enough to me to choose to never go back to RPC. In addition, I don't think my server should be returning me a Java Object. If I wanted to access this outside the context of my GWT application (hey, these "crazy" things may happen), I know Internet Explorer probably can't render it too well -- it has a hard enough time with HTML (zing!).
Allow me to re-introduce the concept of REST.
Representational State Transfer (REST) is an architecture style that, well, kinda does what it says. In the context of Web Apps, it defines how we define, locate, and access resources. If you want the whole scoop, I've got reference links at the bottom. For this exercise, you just need to understand resources and representations.
A resource is the conceptual target of a reference (the reference being, generally, a URL). A file, for example, could be considered a resource. The file's representation can be a number of things, but examples are HTML, XML, GIF image, basically what the user sees. In short, it represents a resource in some meaningful way. For this exercise, let's go with XML as our default representation (it will become painfully apparent why soon).
With RPC, using a method to retrieve some data (a Representation, perhaps) is the standard means. There is a RESTful way to do this a well, and here's the kicker: it's a basic building block of the Internet! The standard CRUD (Create, Read, Update, Delete) operations are already represented as HTTP PUT, GET, POST, and DELETE, respectively. I'd argue that just about anything you'll need to do with a web application can be covered by one or a combination of these functions. I'm not going to get technical today but take my word for it.
Enter RestLet. A lightweight, open-source Java API that acts as a catalyst in developing Web Services in Java to handle ANY general HTTP request. A request from, say, our Web-based GWT application! RestLet employs the principles of REST, transferring representations from the server to the client upon request. Assuming we use XML Represenations, we already have a means of parsing and interpreting these representations client-side ... AJAX, which is at it's core, GWT.
Now, we have a generalized API to program to and access data from. We can use GWT to make requests, but now JSNI, JSP, PHP, even standard HTTP requests are respected. We have a portable server to interpret our requests and the responses (XML representations) are immediately parsable, even by IE (zing!).
In short, employing the principles of REST to ANY web app is incredibly beneficial for a number of reasons that I'll leave to the avid reader to convince themselves of. Roy Fielding has spent plently of time stating things and I don't need to use more. RestLet, an open-source project provides a well-thought out means of utilizing this architecture. And with this, you can finally give that RPC code a REST.
I wanted to use this blog to simply introduce the concept of REST within the context of GWT, how it can be leveraged by AJAX, and how it can be used as an alternative to RPC. If there's any interest, I'll do a follow-up blog or blogs that will delve into the following topics:
- Current Open-Source Applications using REST/RestLet and GWT.
- Open-Source Solutions made to speed up XML processing and leverage REST.
- Creating a RESTful Web Server
- RESTful References and Why They're Essential
This is all information you can dig up yourself, but I'm happy to share. REST and RestLet, of course, aren't the only way to get outside the RPC box, but, from my experience, it works efficiently, encourages robust code, and, most importantly for me, let me say bye-bye to RPC.
To close, I want to say that I don't profess to be a definitive authority on this, and I'm still learning new things everyday. I look forward to any feedback on this you may have, and any other out-the-box ideas.
--
Carl Scott
Software Developer, Solertium Corporation
- Google Web Toolkit: http://code.google.com/webtoolkit/
- Roy Fielding explains REST: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
- RestLet: http://www.restlet.org/
