Mac OS = REST? No way.
Via a crosspost on WebServices.org, I ran across this blogs from Mark Little. He’s right on mark in that the religious debate that occurs between REST proponents and WS-* proponents is very much like debating MacOS versus Windows. In the end, he places REST on the same side as MacOS X. Normally, I’m like Mark in that I take a middle-of-the-road approach. I know that my technology choices are based upon the things that I find important, and that may not be the same set as others. In my case, I am a die-hard Apple user and have been for over 20 years now. I did own one Windows PC for a brief point in time (along with my Mac) and just hated it with a passion. Anyway, to get to the point, my personal preferences are for WS-*. I do think REST has its place, but if it were up to me, I’d stick with WS-*. Given Mark’s analogy, am I now doomed to a life of conflict since my Mac-loving side should point me toward REST?
Where I think the analogy goes south is in equating a minimalist interface to ease of use. Ease of use does not imply taking a least common denominator approach. Ease of use implies presenting the right things to the user at the right point in time, and hiding the complexity that the user doesn’t need to see, if that’s what is warranted. WS-* isn’t about exposing that complexity to every developer. I’m willing to bet that any company that is heavily invested in WS-* development tools would state that there goal is to hide that complexity. Taking it out of the specification merely makes it someone else’s problem. It doesn’t make it easier to use. The only time it could perceived that way is if the solution didn’t warrant it in the first place. That would be akin to Apple marketing Final Cut Pro to all of us making videos of our kids that simply need iMovie. At the same time, it would be just as bad, if not worse, to tell the television and movie studios to use iMovie to build their next big-budget movie or TV show.
The message is that the WS-* development tool vendors need to take a Mac-like approach. Make it easy to use, and hide the complexity. I think they’re well on their way to doing this.
3 Responses to “Mac OS = REST? No way.”
Leave a Reply
“Taking it out of the specification merely makes it someone else’s problem. It doesn’t make it easier to use.”
If you don’t believe it possible to simplify a system through specification, then you are truly lost.
Generalization simplifies. It is trivially and demonstrably simpler to have two data-producing services which produce that data using a common interface than it is to have them use different interfaces.
Generalization also enables standardization. The more reusable the interface, the more cost effective it is to standardize. In a world with an unbounded number of interfaces, standardization is not possible because it’s too expensive.
I do believe it is possible to simplify a system through specification, but I also believe that there are boundaries. Over-simplification takes problems that must be solved and sweeps them under the rug, left for someone else to deal with. Under-simplification is just as risky, either due to paralysis in the standardization effort, or turning everything into a one-off case.
The best solution, in my opinion, is the one that hides the complexity where appropriate, rather than attempting to eliminate it. Yes, there are situations where the complexity is unwarranted, but there are plenty of situations where it is warranted. The problem is not REST versus WS-*, the problem is understanding the problem appropriately and choosing appropriate technologies.
I think you’ve got the basic idea right Todd.
During application design, knowing your user and the task the user
is trying to accomplish is paramount. If you don’t understand
those elements, it doesn’t matter so much what technologies
you choose. The problem is when you are planning a
high level system architecture or creating enterprise-wide
standards that will apply to a variety of application development teams,
you’re often thinking about how to deal with future requirements whose
details are … sketchy! In that situation,
architects tend to go with the technologies that are flexible,
extensible and either de jure or de facto standards.
I think WS-* clearly wins that battle.