Whoah. Lots and lots of action is happening in the blogosphere about the division between Hi REST and Lo REST (which I argued is completely bunk, and still do).

First off, I should mention Koranteng Ofosu-Amaah who, like me, is all about the Elevator Pitch of REST, which he puts a whole lot more succinctly then I did. Good on him.

Mnot also talks about the false choice, but then we go right back into the conversation about which HTTP verbs to use.

Avatars and Definitions

I'd like to respond to someone on the "other side" of the discussion who is making a lot of waves, and, while I may not agree with what he has to say is zeroing in on some good stuff. Ryan Tomayko in his entry TitledThe Highs and Lows of Rest says:

Not being able to distinguish which of these subsets of applied REST one is referring to is hurting our ability to have meaningful conversations about this stuff. For example, consider the following conversation; I�ve seen it hundreds of times now:

Restafarian: 80% of developers use the XXX REST API because they find it easier to deal with.
Tool Vendor: That�s not really REST. It only uses GET and POST and breaks rule #5034
Restafarian: Oh yea, well SOAP/WS-* sucks.
Tool Vendor: Go write some PHP you dirty hippie!

I�d like that to stop happening.

But I don�t think adopting wrong or ambiguous terminology is going to help either. I�d like to register my nits with the few sentences that Dare provided and see if anyone else is thinking along similar lines.

To which there are a few things to say. The first of which, why is the RESTafarian a PHP writing dirty hippy? Have I become some kind of RESTafarian avatar?

Enough funning. The real part that merits a response is that having meaningful conversation about REST Is hard, because there is a real disconnect between what REST means and what people think REST means. In fact, I don't so much have a problem with the idea of splitting REST into a high and low version. What I take issue with is where the split is taking place. For instance, I could see a situation arise where cookies would be used to store an applications state, and this could still be RESTful, and we could call that Lo-REST. I would even go so far as to say that we could break one of RESTS constraints and we can call that Lo-REST. But the point is, that in order to make this Hi and Low REST distinction, we have to be talking about REST, not HTTP. In fact, One could argue that one doesn't need to use HTTP to be RESTful, and it seems to me that Fielding suggests as much in his dissertation when he talks about REST being applied to URI and HTTP.

Another excellent thing that Ryan brings up is the fact that the response entity of the server does not have to be XML for it to be rest. In some cases, a text/plain will be a perfectly valid, and usable resource representation. He also brings up Microformats as a good resource representation (AHAH is what this is called, and it is quite nice actually).

Web services as objects

Apparently my previous entry resonated with Sam Ruby as well, and through checking out his blog, I suddenly got transported into the world of Duck Typing and other misc goodness. Go check it out, you won't be wasting your time, he is on my feedlist. Sam Ruby makes the web-service to object analogy, which I like a lot more then the REST/CRUD analogy, but it still doesn't fit right with me.

I guess as an analogy it works really well with SOAP, since SOAP started out as the Simple Object Access Protocol after all. But I think that the analogy can be carried further, and perhaps expressed differently in the case of REST to promote more understanding (which is not to imply that Sam Ruby doesn't understand REST). When you GET /resource?my&query&string&here, what you are really doing is $myRepresentation = new Resource($my, $query, $string, $here)... and at about this point the analogy starts to break down. POSTing to a resource will perhaps alter the resource itself (thus changing the class), or it may just alter the representation of the resource (changing an instance, and all future instances that "look like it"), or, it may just initiate an action leaving the state of the resource unchanged, but otherwise modify or act on another resource. If you perform a DELETE on a resource, one of the actions that may happen is that a representation of the resource disappears, likened to unset($myRepresentation). But another thing that might happen is that the resource itself will disappear. The only analogy here is that you undefine a class (which only makes sense in a world where classes are first-class entities).

It is in the breakdown of the analogy that (hopefully) promotes more understanding. Essentially what I am saying is that with REST you don't want to think about methods on objects, you don't want to think about storage and retrieval of documents, you want to think about Actions on Universal Resource Indicators, that may contain a representation of a resource, that may return a representation of a resource. From Fielding:

What distinguishes HTTP from RPC isn't the syntax. It isn't even the different characteristics gained from using a stream as a parameter, though that helps to explain why existing RPC mechanisms were not usable for the Web. What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics that can be interpreted by intermediaries almost as well as by the machines that originate services. The result is an application that allows for layers of transformation and indirection that are independent of the information origin, which is very useful for an Internet-scale, multi-organization, anarchically scalable information system. RPC mechanisms, in contrast, are defined in terms of language APIs, not network-based applications.

Notice that Fielding himself makes the HTTP vs. REST distinction here. (For clarity, what makes my above description RESTful is this talk about representations of resources.)

Cleaning up communication

It really is all about clarity of what REST is. REST is a general set of constraints that happen to be really well applied to HTTP. I happen to be working with an application server that is about 70/30 REST, its protocol has nothing to do with HTTP. However, it contains some (but not all) of the architectural constraints that are laid out by Fielding's dissertation.