begin quoting boblq as of Wed, Apr 26, 2006 at 09:31:32AM -0700: [snip] > (messy, coupled client) <---REST---> (messy, coupled server)
I like that diagram. [snip] > You say you failed. The web appears to some to have been > successful. Whose advice should we follow? With that insight, I can see the reason for my failure -- it's obvious. I failed to provide easy access to pornography. :-/ Ahem. But seriously... You're going to do what you want regardless. In fact, I suspect that my suspicion will only encourage several people to jump on that bandwagon, rather than taking a minute to think about the (potential) pitfalls. If Stewart doesn't like it, it must be cool! The problem of software is often one of managing complexity. We can't seem to get rid of it, but we can push it around... alas, if we aren't careful about how we push it around, we add to the overall complexity. I'm suspicious of anything that doesn't clearly state what the tradeoffs are. What's the downside? What do we give up? When the advocates don't cover those questions -- or gloss over the issues with a handwave -- I smell a rat. I've been burned too often by "too good to be true"... You want my advice? Look to the tradeoffs. What's the real cost? Does making something _that_ simple really save any effort in the long run? I'll acknowledge that sometimes it does... but sometimes it doesn't. I'm sure that there are applications where REST is absolutely ideal. Look to the _other_ applications. It's how we end up handling the hard problems that makes a difference, not the easy ones. And I might be wrong. I thought OOP sucked when I believed the pundits that held up C++ as the epitome of OO-ness. (Which is another case of shifting complexity around and making the overall level of complexity increase just to reduce a little complexity somewhere else.) I was wrong about OO, but right, I believe, about C++. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
