Friday, December 21, 2007

Getting distressed with REST

I have been investigating REST recently (specifically in relation to Java implementations). REST as a concept has been around since Roy Fielding wrote his thesis back in 2000. 7 years (very nearly 8) is a very long time in computing but despite this it looks like REST as a topic is still considered to be at the cutting edge.

There are numerous articles about what REST is knocking about the web and they do the subject much better justice than I ever could so I won't write too much academic prose about what REST is (or isn't), if you want the textbook definitions go Google it.

My understanding of the characteristics of REST applications

Apparently the world wide web itself is a REST style architecture. I'm not qualified to discuss what is and isn't technically REST. From my findings, the de-facto understanding of REST applications is that they are considered to be something similar to web services (e.g. a bit like SOAP services). Resources are persistent objects on the web identified by a nice clean URI containing nouns.

These resources can be managed as if it was in a database by the means of using different http methods for access (CREATE, READ, UPDATE, DELETE => PUT, GET, POST, DELETE). Interactions with the service are stateless.

Let's get down to something more Java related

The specific Java REST implementation I have been toying with is Sun's Jersey (part of the GlassFish stable of components) and the reference implementation of JAX-RS (JSR 311). I discovered Jersey through experimenting with NetBeans 6 and it's RESTful Web Services plugin. (Note how NetBeans 6 and Jersey are circa 2007 releases - see what I mean about REST still being cutting edge?). Jersey provides the means to produce REST style web services via the use of annotations (e.g. Java 1.5 circa 2004 technology). The NetBeans 6 plugin just makes things a little simpler (about time that NetBeans gave me a technological advantage - I'm sick of my Eclipse using colleagues having whizzy plugins, like SpringIDE, and with Sun making NetBeans 6 the flagship IDE, rather than Java Studio Creator, this is bound to happen more and more.)

Using Jersey creating RESTful web services is pretty straightforward. It we use our RESTful web services as we would a SOAP service we need a client. Client code for REST services is similarly cutting edge - Apache CXF (descendent of XFire) has what looks like a very promising REST client implementation (which like Jersey is also based on annotations).

A very nice example of a RESTful web application is eXist's (Open Source Native XML Database) REST-Style Web API.

This is where I am getting confused

Up to this point everything has been quite simple. REST looks like just another approach to web services but it isn't that straightforward. My confusion relates to what is meant by Roy's phrase hypermedia as the engine of application state. So far, I have made the assumptions that in REST applications the REST resources are XML data - much like in SOAP services. There is no such restriction in RESTful web services - the output can be XML but it can be HTML, JSON, JavaScript, Images, Applets, Excel files etc. (e.g. any MIME type). The best client for these kinds of things is the web browser - so does that mean that instead of writing REST service clients using Apache CXF I should be able to interact with a REST application purely through the browser? Err, as I understand it, yes, it can mean that...!!!

One of the examples avaiable with the NetBeans RESTful Web Services plugins returns a Google Maps page. This kind of resource would be meaningless to any client other than a capable web browser. In order to interact with such a web service it must include navigation, I think this is what the "hypermedia as the engine of application state" refers to - I think that is what Peter Williams is talking about.

So REST can be a plain old XML web service or it can be some kind of web application. There is a fly in the ointment, most (if not all) browsers only support directly communicating with a server with HTML via the GET and POST methods - so we can't use REST's DELETE or PUT. If we use JavaScript it is possible to make use of more HTTP methods using XMLHttpRequest (AJAX style) but it gets complicated.

I'm still learning so I don't know which REST approach is easiest to implement but I'll certainly have fun trying. The REST concept could mix very well with other futuristic Web 2.0 technologies. Imagine a restful Email server (a la RestMail). It would then be very easy to write a JavaScript email client, wait a minute how does Gmail work again?

Seasons Greetings one and all.


ismjml said...

RESTful services really shine for the programmable web. HTTP was intended to be an application protocol, more than just a mere document fetcher. When I first started learning about REST, I remember thinking, this sounds so clean, shouldn't all my human consumable web apps be RESTful as well?

Unfortunately that's not really practical. Technically, a RESTful web app wouldn't be allowed to use cookies. Yet, I am of the opinion, that having the server keep up with application state can be useful, because browsers aren't really capable of doing this efficiently. So now I just try and temper my zeal for REST with reason, and use it where it's appropriate.

Note: Comment imported. Original by Jason website: at 2007-12-21 15:41