RESTful Myths: Unraveling the Confusion

Myth # 1: (from page 19) "All Web services are message-oriented, because HTTP itself is message oriented." One could argue, in a very loose way, that HTTP is message oriented but it's a bit like saying that airplanes are "ground transport" just because they can travel on the ground. Modern convention says that airplanes are air transport. Modern, popular conventions says that message oriented is asynchronous not synchronous. HTTP is a synchronous transport. Message Oriented Middleware (MOM) is a class of technology that includes JMS, MQ Series, CORBA's Event Service, etc. Generally regarded as connectionless technology. So though one could regard HTTP as message oriented in some general english language sense, those in the industry a long time would not call HTTP "message oriented". HTTP is a connection based, synchronous technology. Nothing wrong with that but it is interesting considering some of the later myths which criticize RPC style technology, where WS-* is singled out.

Myth # 2: REST is not RPC and RPC is in some way bad. When reading this book and watching or participating in discussions on REST there is implicit and explicit criticism of RPC based approaches. But again there is confusion here. The REST folk mean that having an explicit operation/method name in a message or in the invocation is what is meant by RPC. However there are two or three ways that this argument doesn't work and is confusing.

1. Again a terminology confusion. Most people, that have been in the industry for some time, usually refer to RPC when talking about synchronous, connection based communication. The emphasis is on that rather than a rich vocabulary of method names - though that is part of the assumption.
2. HTTP is an RPC model. It's synchronous and connection based. Moreover, it has a relatively rich set of remote procedure vocabulary - POST, PUT, GET, DELETE being some of them. Question: So if someone using CORBA used DII and had an interface with only three or four generic operations like HTTP, would that make it RESTful?

Myth # 3: REST makes things simpler by having a uniform generic interface. There are two ways to approach this. Again I'd put the example of MOM based communications (e.g. JMS), or DII in CORBA. All of these technologies have a uniform interfaces. CORBA has invoke, send_oneway, send_deferred,etc. JMS has publish. Does a uniform interface then make it simpler? Not necessarily because then the application code needs to have more smarts in it for marshaling and message validation etc. The static interfaces defined by using CORBA IDL based proxies or Java interfaces with RMI helped remove this extra work "Let the middleware worry about that," was a reason to use such things. But this is not pure enough for REST. But for most Web facing applicaitons REST works great! But wait a minute, what's this? From page 25: "Instead, as a smart programmer you'll quickly notice the patterns underlying your requests to a given service, and write wrapper methods that abstract away the details of HTTP access." Surely not! Surely this is blasphemy! Could the RESTful be advocating some sort of wrapper proxies? Sounds like it. Hmmmm .... I've said this before in a blog entry called I've been arRESTed! HAving said that I had far less a clue about REST then than I do now.

So some questions for the REST folks:

If I was using JMS and had a different queue defined for each resource and had four messages defined: add, delete, update, and get, and I sent XML payloads using these queues, is that RESTful? By definition it would seem that it is.

I have to conclude the following, just as the REST folks say that Web services and SOAP is hijacked by WS-*, is REST hijacked by HTTP? (In fairness the book does not give out to much about SOAP just the way that most implementations use SOAP.) I mean can RESTful services be implemented using another transport? And can a uniform interface have operations similar but different to HTTP's POST, PUT, DELETE and GET? Is it okay if they map to CRUD?

What about a service where the semantics of HTTP verbs aren't enough? Is REST only useful in it's purest RESTful way for resources that basically only have CRUD interface? What about objects that have richer semantics? Does the semantics (and therefore the verb) get hidden in the data of a PUT? (And therefore break the rules) Or do we have to define more finer resources in order to fit the REST model?

Now at the start I made it clear that I like REST. I do! In fact I think it is really neat. I think it has lots of applications. Again I look forward to implementing a resource oriented architecture using REST. And I'll do it just like Richardson and Ruby suggest. It makes sense.

The bottom line is that REST is a really cool HTTP based and CRUD based architecural style that works great for web based applications. It makes one more interface assumption that helps it a great deal - It assumes that most data is text and so lots of the ugly marshalling issues that would push you towards using other technologies go out the window. You don't need them and therefore REST makes sense. So it makes communiction simple and then you can rely on high speed processors to do any marshalling into various binary types that you might be using in your application code. Again nothing wrong with this for a great deal of applications.

My challenge is that the REST community work with the other communities, including WS-* (the REST community has cute nicknames for this community) to help clear up some of the confusion - and I think some are trying. For example I don't think it's fair to assume that Web services is just HTTP. HTTP is successful for a number of reasons and not just the fact that it has a simple, uniform interface. Remember most enterprise architects got stuck with HTTP because web administrators didn't like opening up lots of ports - no matter how secure the alternative transport/protocol might be. As a result people were doing ugly things like tunneling through HTTP to do B2B. As a result we just had to resign ourselves to the fact that HTTP was the "Web" when it came to outside the firewall. But there is no reason that alternative approaches cannot be used, especially behind the firewall.

And so I think it is important to define some boundaries to where REST works really well and where it doesn't. Let's be honest about it an not have so many ideological wars. REST is really really useful ... so are other approaches.

My expectation is that the response I'll get to this is "he just doesn't get it!" coupled with the "REST can do everything" answer instead of some clarification, some constructive suggestion on how the REST community can be more inclusive while at the same time remaining RESTful, and some best practices. This would not only do a good service to the larger community, as the RESTful Web services book has done a good service educating me, but it would also help the REST community itself because, as the book points out, most REST implementations are not RESTful but "REST-RPC" based. So there is plenty of confusion currently and room for improvement.

I'm not claiming to be a REST expert. I'm not claiming REST is bad. I just want some honest debate and less confusion around the terms. There is a danger that REST might "go to rest" because there is confusion and disagreement. I hope to learn more about REST as I continue to read the book (no doubt some of the above questions are answered in sections I haven't reached yet.)