I was not countering the claim that REST doesn't entail design constraints since at the time I believed OOP itself is a (useful) design constraint (the biggest being no access to state variables, "getters" and "setters" are bad).

But now that I think about it, I realize why people have a hard time understanding REST. It's not a "design" constraint any more than OOP is. It's an implementation constraint. In the case of OOP I think people confuse those notions because they conflate designing a system with designing class heirarches. But OOP doesn't have anything to do with classes. A system is object oriented when the state is private, objects communicate by passing messages and methods are late-bound. Similarly, you don't really design a system to be RESTful, you simply commit to the idea that you never know — a priori — what methods will be available on a resource. You determine them by asking the object and those methods are only valid as long as the cache-control header says they are. Just about everything else follows from that.

> the point is that the network imposes limitations and you often need a domain-specific design to get around them

That's why REST emphasizes caching, stateless communication, the appropriate use of status codes, and the appropriate use of VERBs (idempotent vs non).

> for example, HTTP is awful for soft real-time applications.

I wouldn't write an OS kernel in Ruby either.