Your view of how to solve problems seems very programmer-oriented and not business-oriented.
Stuff like how to process a REST request is simply details. I don't understand why you are focusing so much on this aspect, but I have seen this anti-pattern so often that it repulses me; most examples of RESTful APIs are bullshit, written by people who did not take the time to actually understand REST principles. A good example I documented on my blog is how awful and stupid the ThreeSharp Amazon S3 library is for C#. And writing it in the same style in F# would be just as ugly and stupid! I also discuss why it is a joke that S3 itself is called a REST API, and point out how the language examples in Amazon's documentation is COMPLETELY inconsistent from language to language -- there is no correctness-preservation across language implementations!!!
Incidentally, when people say "web development", they can mean many things, with True REST being just one of them. Most people are actually referring to corporate intranet applications, such as data entry forms and stock analysis tools that chart trends, provide real-time data feeds, etc.
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.
> Actually, you have allocated most of your comment for advertising your blog…
Sorry if it came across that way. I really don't check who reads my blog, there is no comment mechanism, and I do not like linking it anywhere except to friends. Even then, I prefer they not read it directly. My blog is mainly a personal thought dump and collection of links.
Stuff like how to process a REST request is simply details. I don't understand why you are focusing so much on this aspect, but I have seen this anti-pattern so often that it repulses me; most examples of RESTful APIs are bullshit, written by people who did not take the time to actually understand REST principles. A good example I documented on my blog is how awful and stupid the ThreeSharp Amazon S3 library is for C#. And writing it in the same style in F# would be just as ugly and stupid! I also discuss why it is a joke that S3 itself is called a REST API, and point out how the language examples in Amazon's documentation is COMPLETELY inconsistent from language to language -- there is no correctness-preservation across language implementations!!!
Incidentally, when people say "web development", they can mean many things, with True REST being just one of them. Most people are actually referring to corporate intranet applications, such as data entry forms and stock analysis tools that chart trends, provide real-time data feeds, etc.