He writes;

Per my earlier note, I have evaluated my feelings on the units of REST:

and goes on to “support” or “strongly support” all of the high level mandatory constraints of REST.

He also offered some very insightful observations on some of the differences between REST and Web architecture;

REST is a single candidate architecture. And an architecture must be evaluated on the whole, rather than the individual parts. Fielding does a great job of stating that every decision in the candidate architecture has trade-offs. He further identifies the applicability of the architecture (distributed systems, system ‘feels’ stateless, desire to scale, desire to evolve, etc.) Like all candidate architectures, one can only evaluate the architecture against a problem that you are trying to solve. REST by itself can not be evaluated, only evaluated as a candidate solution to a pre-identified problem.

Yes, exactly. Which begs the million dollar question; do you think it applies to machine to machine integration problems? If so, then I’d say that makes you a RESTafarian. Understanding the domain of applicability of an architectural style is very important; it’s not enough to believe, say, that “REST is great when you’re building Web apps for humans”; you’ve got to be able to see beyond that. At least IMHO, since I coined the term “RESTafarian” 8-) (which I’m sure I’ll regret at some point 8-)

What was interesting to me was the lack of association between REST and HTTP, or more precisely the ‘verbs’ of HTTP. Instead, Fielding places significant attention on the need to use Resources (think URI), Self Descriptive Messages (think XML), but does imply that a generic interface is required. Somehow… I find myself agreeing with Fielding but disagreeing with many RESTifarians (I’m not sure how this is possible). Fielding suggests a “a uniform interface between components “, however he never mandates what that interface should be – only stating the characteristics.

Modulo the “think XML” bit, yep. But this is actually one of my very few beefs with REST; the methods do matter. Roy and I talked about this (darn, can’t find the message in rest-discuss); that there should only be one “get me the state of this resource” method. He made some comment about how he didn’t want to list the obvious constraints. But as I’ve discussed, I think that’s quite non-obvious to a lot of smart folk.

However, I find significant ‘folklore’ stating that the interface is, “…defined completely and solely by the specified semantics of HTTP, i.e. GET / PUT / POST, etc.” (Jeff Bone) He continues to argue, “*there are no applications you can think of which cannot be made to fit into the GET / PUT / POST / resources / representations model of the world!*” The only issue I have is his term “made to fit” – meaning, what was the price of ‘making something fit’?

Very much agreed. Jeff sounds like he’s talking about GET/PUT/POST/etc.. as a 100% solution, but I think it’s more like a 97% solution, at least for “loosely coupled, document exchange” style solutions. As I mentioned to Jeff offline, in all my experiences with HTTP, only once have I ever had to use an operation other than GET, PUT, POST, or DELETE (or MONITOR) in order to get something done in a reasonably efficient way; that was to basically implement the functionality of a SQL UPDATE over a large set of resources (a PUT to each resource would have been prohibitively expensive).