Okay. I'll let Alan Kay argue the exact same point then.
http://video.google.com/videoplay?docid=-2950949730059754521
The whole video is worth watching but the relevant part starts at 43:00. This video was made three years before Fielding submitted his dissertation.
(note: this isn't an appeal to authority fallacy since he's making an actual argument.)
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.
Your attempt to enforce some dichotomy between design and implementation is hopelessly misguided.
>That's why REST emphasizes caching, stateless communication, the appropriate use of status codes, and the appropriate use of VERBs (idempotent vs non).
These don't solve the major problems. If I want caching I can trivially implement it myself. It's a useless thing to implement at the architecture level.
Similarly for idempotency etc. It's all a huge academic wank. An appropriately designed protocol will solve all these problems without the constraints.
>I wouldn't write an OS kernel in Ruby either.
What smug yet clueless response. You're begging the question.
I'm frankly bored of talking to someone who knows nothing about protocol design, but defends HTTP as a "proven" technology. It clearly isn't, it fails on many levels, and the whole web stack is completely fucked. Good day.
Legions of computer scientists and computer engineers disagree with you. Caching is fundamentally an architectural concern.
>I'm frankly bored of talking to someone who knows nothing about protocol design....
Please point to your widely commercially deployed protocols before accusing others of ignorance.
> ..but defends HTTP as a "proven" technology. It clearly isn't, it fails on many levels, and the whole web stack is completely fucked. Good day.
You've demonstrated an astounding lack of respect for pretty much everyone on this topic here, and I'm finding it incredulous myself to have to tolerate the amount of bitterness being emanated from you. Why are you participating here it all, unless you just want to tell us we're all clueless, and you can feel superior?