RESTless, RESTFul, or RESTlike?

A couple of weeks ago I ran into my old mentor from my Iona days, Steve Vinoski. I was in shock. The guy I looked up to (and still do) for years, the guy who used to have sideburns the size of Elvis’s turned all “queer” on me. How could the guy who taught me everything I know about distributed systems go all RESTful on me? Telling me basically that he’s hooked and will never go back. I had read a little bit about REST earlier and was a little skeptical, but now I really had to take a closer second look.

Its funny, REST seems to be a bit like learning AOP. With AOP, one or two sentences just doesn’t articulate exactly what it is, or how you are supposed to use it. REST seems very similar in this regard. I’m almost getting it, but am still a bit fuzzy on how to do certain things. Since REST is more of an architectural style rather than a concrete API, I guess my slowness and confusion is a little justified. Or maybe its because RESTful articles and blogs seem to spend so much time trashing SOAP and saying how wa-wa-wa, “the Web is proof of why REST is so great”, in other words, “REST is great because of REST”, and very little time on actual examples is why it takes so much reading to get to the heart of it. I don’t know…. Maybe its all my CORBA baggage? All my Java EE baggage? Anyways, I don’t want to go into yet another, what is REST blog. If you want information on the definition of REST, the REST Wiki is a better source, found this link too. No, what I want to do is go through my own thought process to see if the REST way of things is the golden path. To do that I want to walk through some of the basic cornerstones of REST.

Use of URIs

One of the cornerstones of REST is to have resource location modeled as a URI. This seems like a no brainer. When we modeled our EJB 3.0 container on top of JBoss Remoting, which is URL based, our design became much simpler and things like request failover were much easier to write. Yeah, yeah, not every EJB has its own URI, but moving to URI based endpoints made implementation easier. So +1 for REST here. Its interesting though. How many times do we run into issues in Java EE land because it does not define unified addressing of its services? Its been a big roadblock in writing portable frameworks. WS-* has to have a whole spec on the subject, funny eh?

Uniform Interface

RESTful articles make a good analogy between SQL and the RESTFul architecture. I won’t paraphrase, but instead, directly quote:

It is nevertheless imperative to question our basic assumptions. Consider a similar debate taking place in the 1960s. A radical researcher within IBM states that it is incredibly inefficient for each application to determine for itself how to store, index and search its data. He proposes the concept of a “generalized database”. Clearly this “database” would not be as optimized for a particular problem domain as a specialized data store. But then imagine the interoperability benefits if many applications could access the same data in a uniform fashion. Then, later, another IBM researcher makes an even more ridiculous claim. He states that the vast majority of the structured information in the world can be manipulated with only four operations: SELECT/INSERT/UPDATE/DELETE. Ludicrous! What about AddCustomerRecord, DeleteCustomerRecord, InsertCustomerRecord, UpdateCustomerRecord?

The idea is, that in a RESTful architecture, everything is modeled in terms of resources accessed through a URI, and only 4 CRUD HTTP operations of GET, POST, PUT, and DELETE. From my perspective it is very counter-intuitive to express object interfaces in terms of 4 methods. Doesn’t make much sense as an object designer of local models, but for distributed systems, it does make a lot of sense I think. The CORBA in me balked at this idea, but then I thought about it a little more. How many of us had interoperability problems between different vendors or even different versions? Not only that, but in WS-* land most of the time you need to generate and compile stubs so that you can actually invoke on a web service. With REST, all you need is a HTTP client library. With WS-* you need the HTTP client library plus all the other junk. While HTTP is a mature, well-known, agreed-upon protocol, WS-* is such a moving target.

The question is, with the uniform interface of GET, PUT, POST, and DELETE, aren’t we just pushing the complexity to the content type? To the data that is being transferred and received? I had this very same argument with Vinoski. After thinking about it for awhile, i’ll say, that SOAP has the exact same problem. With SOAP, you still have to define and agree upon the API. The REST approach seems simpler because the protocol is set and simple, it doesn’t have the baggage of SOAP which is a protocol tunneled over another protocol (HTTP).

With the uniform interface approach, it does seem like it would be a lot easier to model security roles. It would just be assigning CRUD permissions really instead of assigning individual permissions to each method like you do in Java EE land. Caching is obvious because GET should mean the operation is idempotent. I don’t know…uniform interface and protocol seems pretty compelling.Content-type

Don’t have a lot to say here other than, doesn’t XML schema sort of make SOAP obsolete?

Statelessness

I remember one of the students in the JBoss advanced training a few years ago talking about holding the state of a SFSB in the client proxy and transferring it to the server with every request. This would make sessions really failure proof and make the server fully scalable. An interesting idea. I was thinking that this could be done with Seam conversations as well, i’ll get into that in another blog in a few weeks or so. This idea of the client maintaining conversational state and passing it to the server is compelling, at least in theory. My last blog I talked the JBoss Business Activity service. What if the client was the coordinator for business activities and managed all compensations? The idea focuses around a quote I read in O’Reilly’s RESTful Web Services book:

The client should be in charge of managing its own path through the application

I’d like to dive into this more in future blogs on both Seam and BA. But all these ideas sound pretty RESTlike to me, at least in terms of statelessness.

That’s all for now

Well, I pretty much asked more questions than I answered here. Probably didn’t enlighten you, dear reader, at all about REST. Maybe confused you a little more? Or maybe I just showed how much I am confused? :-) Like AOP, I think I have to actually implement something RESTful before I actually understand if it is the right approach. Right now I’ll say my leaning are neither RESTless nor RESTFul, but rather RESTlike. Who knows, I’ll probably end up getting angry at both approaches(SOAP and REST) and design my own BURKEful way of doing things. Such a burkeful architecture would definately only work on JBoss though ;-) Let’s see what happens….

P.S.

It is fate. A day after I wrote this blog (I write a few days or weeks before I publish), this TSS article came out. I’m also taking a look at O’Reilly’s Restful Web Services book. I’ll let you know sometime how it goes.

One thing that I fail to grasp is how a ‘restful’ request is different from a parameterized GET request. It is less uniform yet more powerful and it still has the benefit of little complexity as opposed to WS-*.

Dylan, from what I’ve read so far, parameterized GET is still restful as long as you obey the rules of REST for GET. Meaning as long as you are not doing changes to the state of the resource, parameterized gets are ok.