It seems as if ReST has reached some sort of tipping point: different schools of ReSTfulness are starting to appear, and its original creator has a challenging time defending what defines 'true' ReSTfulness. As architects of a ReST-centric web application development framework, it's the kind of tension which shows interesting times are ahead of us, and a call for caution to do the right thing.
I'm particularly struck by this blog post from (very) old acquaintance Dave Pawson, who I enjoyed meeting many years ago at an XSLT training course then organized by the Belgian SGML Users Group's president Paul Hermans. Talk about dinosaur memories. ;-) Here's what Dave writes on the ongoing debate between 'true' ReST designs and their more diluted forms:
Ten years ago I saw James Clark in action on DSSSL then XSLT. I gave him a nickname, BSOP, brain the size of a planet (Hitchhikers reference). James seems to operate on a level (and I'm told at a speed) quite different from mere mortals. Others whose opinions I value have confirmed this. No complaint from me, I'm grateful for what James has given freely to the world of software. The perspective though is that the James's of this world are few and far between. Never having met Roy, I've heard enough to believe that he's quite possibly in a similar category. His thinking seems far enough away from the people that are approaching REST for the first time that there is almost too big a gap. Roy has forgotten more than most are likely to learn about HTTP. When I want to use REST to get a message over that's the focus, not architectural issues. I think this is one of the reasons that REST is still misunderstood. Until such as Paul and a good few others do some really good job of 'translating' from architecture to ... whatever you want to call the practical layer of thinking that more common folk work at, then REST will be misunderstood, 'adapted for use' and otherwise abused due to misunderstanding.
I'm almost convinced that Roy can't | won't | is too busy to do such a translation. It's down to others to try.
Like it or not, this is one of the challenges ahead of us when trying to raise awareness (and sympathy) for Kauri. Rather than the technical details, which is all fairly mundane Java stuff anyways, what we should try to achieve with Kauri is to create some practical level of can-do-mentality with Java developers, while gently guiding them to do ReST the right way.
And not step into the trap of alienating ourselves from the user community on the basis of principles rather than usefulness. Kauri should bring usefulness to ReSTfulness.
Marc and I will be preaching ReST for Java folks on December 8th at Devoxx, so by then we should be ready with some real answers.
Interesting times ahead.