Its easy to just create a programming model for handling basic HTTP requests. That was done years ago- in the Java world servlets and more. However, that doesn’t sovle the problem of how to handle the payload and make links that capture the state of the application in the form of those links. The part of REST which appears hard to get right at first is that of understanding how to make correct URIs and use the HTTP verbs correctly, but the really hard part IMO is how to manage the payload and have it capture links that capture the state of the application. The information Web has it a bit easy here .. the “state” is mostly captured in the current document and links just (relatively) navigate out of it - doing that for non-information-oriented RESTful applications is an order of magnitude harder. In other words, coming up with a solid programming model for resources is non-trivial .. and that’s why we’re still talking and debating about it.
IMO the real underlying problem is that as long as programmers expect to write a class and flip a switch to get a service or one or more RESTful resources then we have nothing really but RPC masquerading as something else. Both resource and service advocates would be well-off in trying to move the developer community to get past the “class is all I need” stage. If REST is successful in getting developers to get their hands dirty more power to it.
+1. And that says a lot ;-)