In his post Going Down To The Crossroads… Don Box uses the terms Lo-REST and Hi-REST to describe classes of services on the Web. Specifically he writes
This one is a bit tougher to catalog, because REST is a fairly subjective (and
sometimes divisive) term. To get a more accurate picture of what we've done so
far, I'll break this category in two: Lo-Rest, which is the use
of HTTP GET (or equiv) for information retrieval/query, and
Hi-Rest, which is characterized by the use of HTTP PUT and
DELETE (or equiv) for doing update.
Although I agree that there is a difference in theory versus practice in how various services that claim to be RESTful are implemented, I'm not sure I agree with Don's definitions. The way Don's definitions read, it looks like the categories of RESTful services are those that only perform information retrieval using GET such as RSS feeds and does that use a wider gamut of HTTP verbs such as the Atom Publishing Protocol. However if you read further into Don's post it seems that he means something else, especially when he writes
With the exception of our DAV support (listed above), most Microsoft
technologies that update stores over HTTP tunnel server-specific update requests
through HTTP INVOKEPOST the way the rest of the apps on the web
do. Hence the need to distinguish between Hi-Rest and Lo-Rest
So now it seems Don's definitions of Lo-REST and Hi-REST refer respectively to applications which misuse HTTP verbs and those that use HTTP correctly. I don't think it is a good idea to call the latter class of applications RESTful because it muddies the term. In my post Misunderstanding REST: A look at the Bloglines, del.icio.us and Flickr APIs I wrote about APIs on the Web that claimed to be RESTful but actually were just Plain Old XML over HTTP (POX/HTTP) services not RESTful services. I prefer to use the term Plain Old XML (POX) to describe these services because it is closer to the truth. These services aren't much different from SOAP-based web services in how they abuse the Web, the only difference is that they have eschewed the baggage and complexity of being based on WS-* technologies.
Once one takes a hard look at the Web, it is hard to find truly a lot of RESTful services. Many misuse GET by not only using it for information retrieval but also for updates and deletes (e.g Bloglines sync API and the del.icio.us API). Others simply tunnel all updates, deletes and state changes through POST (e.g. the Flickr API). In practice, the verbs used primarily on the Web are GET for information retrieval and POST for everything else. WebDAV is probably the only widely deployed exception to this rule.
Don's definitions can probably be altered a little to become
Lo-Rest, which is the use
of HTTP GET (or equiv) for information retrieval/query and POST for everything else, and
Hi-Rest, which is characterized by the use of distinct HTTP methods to perform distinct operations on resources, for example using HTTP PUT and
DELETE (or equiv) for doing update.
This definition draws a distinction between REST as it is practiced on the Web today (i.e. Lo-REST) and REST as it should be practiced on the Web today (i.e. Hi-REST).
A couple of other folks also disagreed with Don's definitions. They include Jonnay in his post Hi-Rest and Lo-Rest, two broken halves of the tower of Babylon and Dimitri Glazkov Lo-REST: This is your REST on Crack who both argue that Lo-REST does not satisfy the REST architectural style. I agree with them, however I also think that it is fair to draw a distinction between what actually exists on the Web today and what should exist on the Web.