Steve Vinoski's Blog

I figured the decentralized media types idea that Stefan Tilkov and I each wrote about recently couldn’t be all that simple. So, not surprisingly, it turns out that at least Mark Baker (and according to Mark, also Mark Nottingham (mnot) as well), Bill de hÓra, and James Snell don’t like it. When either Mark or Mark speaks on matters pertaining to the web, I listen; I’ve been around each of them long enough to know that when they aren’t sure whether something is a good idea, it’s definitely worthwhile to take the time to understand why. I don’t believe I’ve ever met Bill or James in person, but I read their blogs for a good reason, plus James just got his blue belt so I’d like to avoid getting on his bad side. :-)

I particularly like Stu Charlton’s opinion on the matter, though, in part because he acknowledges the tension between the needs of the Internet vs. those of intranets.

At the end of the day, I understand the various explanations for why decentralizing media types is not a good idea after all, and I agree with them. I was unaware that mnot had already tried to go down this path. I see this issue as another stop along the way to a more thorough understanding of REST, and bringing it up has gotten some good technical explanations out in the open, where perhaps more people can see them and learn from them. Thanks to those mentioned above for providing those explanations, and to Stefan for kicking off the discussion.

In RESTful systems, media types define the formats of data exchanged between client and server. Standard media types are centrally registered and managed via the Internet Assigned Numbers Authority (IANA). If none of the registered IANA media types fits your application, you’re free to write up and submit a new one that does.

Less than one week ago I was wondering to myself why media types are centrally managed when the web typically prefers decentralization. I was therefore pleasantly surprised today when I read Stefan Tilkov’s posting on this very topic. The proposed solution he describes, from Sanjiva Weerawarana, Paul Fremantle, Jonathan Marsh, and James Clark, is pretty much in line with what I was thinking: register a new media type that has a URI parameter for identifying an actual data description. Very simple and yet potentially extremely effective.

I like this approach for several reasons beyond just the decentralization win. First, this allows us to gain experience with new media types before they’re standardized. Second, this augments rather than replaces the current IANA registration approach, and doesn’t break the existing IANA registration process in any way. Third, it doesn’t break or otherwise negatively impact any existing applications.

So, enough emailing and blogging about it — who’s going to write it and submit it to the IANA? I hereby offer to pitch in and help in whatever way I can.

As you may know, I’m a columnist for IEEE Internet Computing (IC), and I’m also on their editorial board. Our annual board meeting is coming up, so to help with planning, we’ve issued a call for special issue proposals.

The topics that typically come up in this blog and others it connects to are pretty much all fair game as special issue topics: REST and the programmatic web, service definition languages, scalability issues, intermediation, tools, reuse, development languages, back-end integration, etc. Putting together a special issue doesn’t take a lot of work, either. It requires you to find 3-4 authors each willing to contribute an article, reviewers to review those articles (and IC can help with that), and a couple others to work with you as editors. As editors you also have to write a brief introduction for the special issue. I’ve done a few special issues over the years and if you enlist the right authors, it’s a lot less work than you might think.

As far as technical magazines go, IC is typically one of the most cited, usually second only to IEEE Software, as measured by independent firms. I think one reason for this is that it has a nice balance of industry and academic articles, so its pages provide information relevant to both the practitioner and the researcher.

Regarding the REST and IDL discussion, Joe Gregorio already wrote an excellent explanation six months ago. Perhaps the rest of us should have just linked to it to begin with and avoided wasting our time rehashing it all.

But then again, rehashing is fun! :-) On the same topic, I agree with much of what Dare said, except for this:

When building services with WS-*, you have a WSDL to describe your methods & expected inputs/outputs and XSD schema(s) to describe the schemas for said inputs/outputs. When building a RESTful Web Service, the need for both of these documents does not go away regardless of how often you repeat the phrase “uniform interface”.

I still disagree. The HTTP verb set defines a RESTful uniform interface. When comparing CORBA IDL or WSDL to HTTP web services, that verb set must be considered because it’s the only thing that you can directly relate to IDL and WSDL interfaces. Otherwise, you’re talking apples and oranges. The uniform HTTP interface is the only way for applications to interact with web resources in the same sense that CORBA applications interact with CORBA objects, and WSDL applications interact with WSDL services.

Much of the typical IDL and WSDL definition is devoted to defining one or more specialized interfaces consisting of specialized methods/operations and specialized data types to pass across them. For web resources that use the uniform interface, however, there’s simply no need whatsoever to define interfaces like that. What are you going to do, define GET again and again for each of your resources, each time with exactly the same semantics already specified in RFC 2616? Obviously not.

It’s easy to see that Joe’s OpenSearch document bears no semantic resemblance to a CORBA IDL or WSDL definition. Similarly, an AtomPub service document is nothing like IDL or WSDL either. Both of those documents essentially inform you of service URIs and media types, but they don’t define methods or operations. They don’t have to, because of the HTTP uniform interface. That’s important, and it’s why I disagree with Dare’s point quoted above.

Consider the mindset of the CORBA and WS-* developer. They use systems that force them to always think about all their service endpoints in terms of specialized interfaces. Given how much time I’ve spent in that world (and don’t forget, I still use CORBA too), I know for certain that the concept of the uniform interface is one of the big items that trips these developers up when they try to figure out what REST is about. It’s therefore important to keep the uniform interface as part of the conversation.

Mark Baker:

I’ve had enough. I’m not participating in any more “REST vs. SOAP” discussions. When I started on this mission to educate those who didn’t understand how the Web could help them, I figured it would be pretty straightforward; I’d explain it, they’d understand, and then we’d all skip away hand-in-hand whistling show tunes. Of course, it didn’t quite work out that way. Instead, I ended up spending on the order of $100K of my own money on travel, as well as the opportunity cost of many hundreds of otherwise billable hours, for what is working out to be essentially nothing in return. If that weren’t enough, my health has suffered the past year or so, in ways I won’t get into here, but that I’m confident are in part attributable to the despair I’ve felt over this extended period of frustration.

Mark, I’m sorry to hear about your situation, and I certainly can’t blame you for your decision. As you say, the war really has been won, and you’ve more than earned a break. I saw you take many arrows — and I mean many arrows — over the years as you patiently explained REST to the world and worked hard to keep the wrong technical things from happening in the standards committees. For whatever it’s worth, I greatly admire and applaud your strength and your perseverance, and congratulate you on your achievements.

I also want to sincerely thank you for personally bringing REST to my attention in an email exchange way back around 2000-2001. Over the years REST has helped transform and improve the way I view and develop distributed systems, so much so that it played a big part in my decision to leave a long and well-established career in middleware development about a year ago and switch to developing software for an entirely different industry. In my current position, I’m thankfully free to use REST when and where it makes sense without having to fight all the stupid battles that you’ve understandably grown weary of.

An aside: the personal toll that Mark is suffering is most unfortunate. There’s simply no room in technical discussions for the negativity and hate that causes situations like that. Yet, despite the fact that the war is indeed over, and even though most of us now try to boringly proceed with useful logical discussions, there are still a few hostile jerks out there who didn’t get the memo. For example, I recently had to completely ban one such jackass from commenting here due to his continued personal attacks and insults, not only against me but against Mark, Tim Bray, and anyone else who supports REST. (Thankfully he adds no technical insight or knowledge whatsoever to either side of the discussion, so it’s no loss.) It saddens me that the destructive voices of hate like his can sometimes drive the bright, insightful and truly useful voices like Mark’s out of a technical conversation. It’s up to all of us to continuously try to prevent such situations, whether we’re discussing REST or some other topic.

Mark, thanks again for all your efforts. If there’s any way you think I can help, don’t hesitate to let me know.