As he said this "The REST-* effort might end up documenting what already exists which indicates that part of the challenge is that lots of people don't really know what REST is and certainly struggle as they look to build higher class systems and interoperate between organisations.
Part of this is of course about up-front contracts and the early v late validation questions. But part of it also appears to be pure snobbery and a desire to retain arcane knowledge which goes back to that "Art v Engineering" debate.
A few choice quotes from twitter
"Dear REST-*. Get a fucking clue. Atom and AtomPub already do messaging. No new specification needed, that's just bullshit busy work." - Jim Webber
"REST might lack clear guidelines, but something called REST-* with a bunch of vendors is hardly going to help!" - Jim again
"and if they think REST lacks guidelines for messaging/security/reliability/etc.., they're not looking hard enough" - Mark Baker
Now part of Mark Little's point appears to be that we need more clarity around what good should be in the REST world and this needs to be easier to access than it currently is. I've seen some things described as REST that were truly horrific and I've seen other bits in REST that were a superb use of that approach. The problem that all of them had was in learning about Atom, AtomPub how to use them, how to use MIME types and of course the balance between up front contracts and late evaluation.
Would it really be such a bad thing to have an effort that got people together and had them agree on the best practices and then have the vendors support developers in delivering against that practice?
The answer of course is only yes if you want to remain "1337" with your arcane skills where you can abuse people for their lack of knowledge of AtomPub and decry their use of POST where quite clearly a DELETE should have been used.
If REST really is some sword of Damocles that can cut through the integration challenges of enterprises and the world then what is the problem with documenting how it does this and having a few standards that make it much clearer how people should be developing. Most importantly so people (SAP and Oracle for instance) can create REST interfaces in a standardised way that can be simply consumed by other vendors solutions. It can decide whether WADL is required and whether Atom and AtomPub really cover all of the enterprise scenarios or at least all of the ones that count (i.e. lets not have a REST-TX to match the abomination of WS-TX).
This shouldn't be an effort like WS-*, its first stage should be to do what Mark Little suggested and just document what is already there is a consistent and agreed manner which vendors, developers and enterprises can agree on as the starting point and that this starting point would be clearly documented under some form of "standards" process.
Would that be a bad thing?
Update: Just found out that one of the two things that they want to do is REST-TX... its like two blind men fighting.
Technorati Tags: SOA, Service Architecture
4 comments:
The references to messaging and transactions are meant as discussion points only. Certainly the transactions specs were done 8+ years ago.
Apart from that a big +1
I agree as well. It wouldn't hurt to get people involved in trying to document best practises and then take it from there and standardize some things. A large percentage doesn't know when to use PUT or POST! And yet they claim RESTfulness...
It's not even about the specific documents I think (TX or else). It's about the effort in itself. But I see RESTafarians being unreasonably aggressive against this, when I think they should get on and try to keep things on track.
That said, maybe the name should have been different...
I tend to agree with the REST people here, and I don't see how it conflicts with what you are saying Steve.
They just don't want the word "REST" and "standardization". If there intended goal is to write down best practices, say that and get it over with. REST-* is just a cheap attempt at saying "we will tell you how to do all WS-* stuff RESTfully" , which pisses off most RESTafarians because they believe ( and I agree) that WS-* is fundamentally flawed for internet scale applications. It failed in Enterprises probably because it was overly complex , but for internet scale apps it is just wrong wrong WRONG!
And Roy Fielding couldn't give two hoots about anyone using REST for enterprise applications -- he has designed it only for Internet Scale applications, a major requirement of which is anarchical growth, which is not true for Enterprise apps mostly. What JBoss and other enterprise people are trying to do is get a little bit of simplicity into enterprise apps -- note SIMPLICITY! .. thats all. They belatedly recognised the KISS principle but are trying to unnecessarily call it REST cos its cool right now.
And that is a load of crap!
Maybe it's the way Bill's explaining it that's not getting through, but this is NOT about telling people how to do anything. The aim is to get people with experience to come together in a community forum and help define the best ways of solving various problems in a RESTful manner. Maybe as a result the community will find holes in current thinking/practices and that would lead to proposals and changes to be applied through, say, IETF. Alternatively maybe the community would find that the world of REST (and HTTP) is perfect and doesn't need anything more; that's a fine outcome too, though I'm open minded enough to not assume one outcome or the other at present. Anyway, since the initial posts, Bill has changed a lot on the site and tried to accommodate people's views. As to the name, I'd probably change it too, but it's an open source project so it's down to Bill and the community.
Post a Comment