Well REST and RESTful are at this point mostly buzzwords. I'd be happy to just use “Correct-HTTP” instead of REST and “Correct-HTTP+hyperlinks” instead of RESTf

Well REST and RESTful are at this point mostly buzzwords. I'd be happy to just use “Correct-HTTP” instead of REST and “Correct-HTTP+hyperlinks” instead of RESTful, especially since no one actually uses REST or RESTful when describing things, that do work by exchanging representations, outside of HTTP and webapps context. I don't actually get what there is relevant about any possible business-oriented perspective you mention at the beginning. Actually, you have allocated most of your comment for advertising your blog… As to your last paragraph, there's nothing like True REST etc. I'm not buzzword happy and I don't generalize things like that, as you can see in my other comments anyway. I wasn't referring to all those irrelevant things you've mentioned. My observation was that most web development—of various sort—was done by keeping state server-side. That approach is fine as long as you don't have multiple pieces of independent logic on one page. In that case the whole thing becomes complicated—you can either 1) use text-processing techniques, which is my hypothesis for why languages like PHP, Python and Perl are so popular for webdev or 2) abstract stateless HTTP protocol away, which results with very unfriendly and difficult to scale artifacts, like continuations. The separations of concerns: server logic and presentation, that is possible by properly utilizing HTTP and by having powerful enough client-side environment (Javascript VMs) enable for a much saner approach, and that's why I think strongly typed languages are relevant for web once again. Hope this clarifies my position :)