Look, at the end of the day, if your system wants to misuse HTTP, abuse HTML, and carnally violate the principles of loose coupling and resource representation that underlie REST, who cares? Do you get special bonus points from the Apache Foundation if you use HTTP in the way Fielding intended? Will Microsoft and Oracle and Sun and IBM offer you discounts on your next software purchases if you create a REST-faithful system? Will the partisan politics in Washington, or the tribal conflicts in the Middle East, or even the widely-misnamed "REST-vs-SOAP" debates come to an end if you only figure out a way to make hypermedia the core engine of your application state?
Yeah, I didn't think so, either.
Point is, REST is just an architectural style. It is nothing more than another entry alongside such things as client-server, n-tier, distributed objects, service-oriented, and embedded systems. REST is just a tool for thinking about how to build an application, and it's high time we kick it off the pedastal on which we've placed it and let it come back down to earth with the rest of us mortals. HTTP is useful, but not sufficient, so solve our problems. REST is as well.
And at the end of the day, when we put one tool from our tool belt "above all others", we end up building some truly horrendous crap.
Ted is, of course, absolutely right. If you feel this sounds different from what I usually write around here, and talk about elsewhere: I spend a lot of time talking about REST, and its advantages as I perceive them, but of course that doesn't mean it's the perfect or even feasible solution for every problem.
It's just a lot more powerful than many people think, and most do so because they don't know enough about it. Ted is not one of them.