03/05/10 :: [REST] RESTless in Seattle [permalink]
Lori MacVittie wrote a following post to my post on REST that is both refreshing and terrifying. Refreshing because well it kind of puts together a lot of the untold truth of our industry:
- Standards sucks and are ever changing, they don't fit with each other or offer some kind of upward compatibility
- REST is not as "easy" as some people would like others to believe it is
- Innovation in 2010 is no free lunch, lots of people who don't understand a thing about innovation get in the way for various reason (greed, fud, ego...) and the innovators have to deal day in and day out with their stupid goals and constrains, not to mention unsustainable ROI
Thank you Lori. It's refreshing that someone is not talking about the Lalaland of XYZ and is not afraid of using "real" words, not to mention avoid bolonizing their readers. There are so few like you that it is worth mentioning.
Your post is also terrifying because it leaves little hope to achieve building anything right. Actually, the probability to get the right thing accomplished is as high as winning the lottery. In many ways, I agree with you. When you see products like the iPhone and you think at the alignment of technologies that needed to happen to realize such a device, only a strong culture and "proprietarism" can deliver any kind of innovation today. Standards are the wrong approach to innovation. They kill innovation. Pretending innovation is easy is the biggest lie of the 21st century. No, innovation is complex and requires a bunch of smart people working together without just ROI, greed, or fear as a driver. I think the next decade will see the emergence of new winners who understand innovation at that level. Of course, there are counter examples to my argument, company like WSO2 have innovated on top of less than optimal standards, but I think they remain the exception, and it is probably due to their strong culture and sense of values.
Stu also provided a follow up to my challenge to define a version strategy. Don't get me wrong, I like Stu, he is incredibly competent and he backs his work with a long experience. But, Stu failed to provide a compelling strategy for versioning. He actually admits that:
In a RESTful approach, URIs are your "foreign keys", and if you embed a version identifier in them, they need to change when you upgrade to the next version if you embed those versions in the URI. Assuming you can't convince your resource owners to use languages with version identifiers as a MIME parameter or inside the language itself, how is that done?
This is what I mean by REST couples access and identity.
Stu also conveniently forgets to speak about the "unit of versioning". Nearly every resource is participating in different lifecycles. A resource has different states, composite states. Each lifecycle has a set of actions (which are always encoded as POST+noun in REST). This is the unit of versioning. A comment from Mike actually speaks to that very problem:
there are many times when an application-flow update requires support for side-by-side versioning
Yeah, the RESTafarians finally touch the real problems or building real systems, not just blog posts and plain vanilla articles or useless annotations. I actually argue that without the visibility of an explicit lifecycle, these problems are impossible to solve. You can't version an action API if you don't understand the states and transitions behind them.
Of course, people like Stu or Mike will never admit such a thing publicly. They will always say, "but... if you look here ... there is a promising solution that that problem". Boloney guys. Pure and complete boloney. We have endured 3 years of that boloney. REST is not a programming model. It has never been and it will never be. Deal with it.
I have ordered Subbu's book (hopefully he will give me an autograph), so I'll wait until I get it to make my final comments on versioning, but so far I think (reluctantly) that Stu belongs to the REST wall of shame. It is time to get real and provide real recommendations. Recommendations that don't let people loose like the ones that have been made for so long and got us where we are today, i.e. nowhere.
I see no success in sight and no sign of possible success either. The (other) REST is a fraud, nothing less, nothing more. Innovation is not "serendipitous" innovation requires hard work and courage. Innovation doesn't happen in pretty power points and IEEE articles.
RESTfully yours,
JJ-