Steve Vinoski’s Blog

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.

I have to say that I agree with Ryan Tomayko on this one.

Among other things, Ryan touches on one of the favorite assertions of the REST detractors, which is that REST can’t be effective without an interface/service/resource definition language. After all, without such a language, how can you generate code, which in turn will ease the development of the distributed system by making it all look like a local system? Not surprisingly, the first comment on Ryan’s blog entry is exactly along these lines.

As I’ve been saying for years, trying to reverse-map your programming language classes into distributed services, such as via Special Object Annotations, is an attempt to turn local design artifacts into distributed ones, which we learned long ago is just plain wrong. You often end up paying for such shortcuts in areas such as reliability, flexibility, extensibility, versioning, reusability, and especially scalability.

Back in the halcyon days of CORBA, we generated code from OMG IDL, but IDL is not a local design artifact. OMG IDL was designed from Day One to define distributed systems (though we did add the “local” keyword to IDL sometime around 1999 or so to allow for easier local call optimizations). Note also that unlike the usual approach to defining WSDL, we never reverse-generated IDL from C++, Java, or any other programming language (though a questionable group eventually did come along and, trying to ride the Java popularity wave, define an OMG standard reverse IDL mapping for Java, despite strenuous objections from a number of us, including me). IDL also allowed for generating code in different programming languages for different parts of the same system. But the RPC roots of CORBA, its interface specialization requirements, and the inflexibility of the generated code, especially with respect to versioning, ultimately limited CORBA’s possibilities when it came to medium- to large-scale systems.

Proponents of definition languages seem to assert that such languages help with understandability. Such languages, they say, are required because they alone tell you how to invoke the service, what to pass to it, and what to expect in return. The problem with the way they make this assertion, though, is they make it sound like the application figures all that stuff out on its own with no human involvement. What happens in reality is that an actual human programmer sits down, reads the interface definition, more than likely reads some comments in the definition or a whole separate document that describes the interface in more detail, and perhaps even talks to the person who wrote the interface definition in the first place. Based on the knowledge gained, he then writes the application to call that interface. Similarly, with REST, you read the documentation and you write your applications appropriately, but of course the focus is different because the interface is uniform. Depending on the system, and assuming REST as implemented by HTTP, you might also be able to interact with it via your browser to help understand how it works, which I’ve found extremely valuable in practice (and yes, this works for application-to-application systems that are not designed primarily for browsers or human consumption). But ultimately, there’s no magic, regardless of whether or not you have a definition language.

What the proponents of definition languages seem to miss is that such languages are primarily geared towards generating tedious interface-specific code, which is required only because the underlying system forces you to specialize your interfaces in the first place. Keep in mind that specialized interfaces represent specialized protocols, and IDL was developed oh so long ago to generate the nontrivial code required to have RPC applications efficiently interact over such protocols, since back then computers and networks were far slower and less reliable than they are today, and getting that code right was really hard. When you have a uniform interface, though, the need to generate interface-specific interaction code basically goes away.

(BTW, the first IDL I ever saw was at Apollo, where it was used not only for RPC in the Apollo Network Computing System (NCS) but also to define Domain/OS header files once and generate them into their C and Domain Pascal equivalents, rather than writing and maintaining them twice, once for each language.)

Some REST proponents like WADL. I’ve looked at it but haven’t used it, so I can’t really comment on it. I’ve never felt the need to seek out a resource definition language of any kind for my REST work, at least to date. YMMV.

BTW, on a somewhat related note, I still use CORBA, contrary to what some jackasses out there would like you to believe. In some industries, certain CORBA interfaces are standardized and even legally enforced. In others, leading players have defined CORBA interfaces for 3rd-party integration. These interfaces work, so those companies and industries have no intention of changing them to another technology anytime soon, and in fact they simply have no need to change them at all. I’ve had to work within some of these CORBA scenarios lately, and I have to say I’ve found it to be fun, like meeting up with an old friend you haven’t seen in awhile. I’m sure many of these interfaces could be done better with REST, but they work as is, and there’s just no need to throw them out. Coincidentally Ryan spoke of CORBA when he responded to the commenter mentioned above. All in all, I remain proud of my CORBA work over the years, as we did a lot of good stuff back then, even if since then we’ve found simpler ways of doing a few things.

Reusability is often promoted not only as a goal but also as a feature of all kinds of software architectures, designs, and systems. For example, in the CORBA, WS-*, and SOA worlds I formerly haunted, everyone spoke nonchalantly of reuse as if it were a given. You were supposed to simply identify the objects or services required to support your business processes, and then specify their interfaces. Then, anyone wanting to provide one or more of those objects or services was merely supposed to follow the appropriate interfaces and write implementations for them. Applications were written to the interfaces and thus were automatically decoupled from the implementations. As a result of these reusable interfaces, you could also potentially reuse the objects and services that implemented them, as well as the applications that consumed them.

Problem is, it never seemed to work out as easily as that. Most of the time, the interfaces people came up with were just too specific, and nobody could agree to apply them widely. Think of all the time people spent over the years in OMG, JSR, and W3C WS meetings trying to agree on just the infrastructure interfaces and not always succeeding. It’s therefore not surprising that there was never much success at defining broadly-accepted standard interfaces up at the application level; the scope is simply far too wide up there.

So, with technologies that promote interface variability, planned reuse is pretty hard. Consequently, serendipitous reuse, where services and facilities can be combined and reused beneficially in unforeseen ways, is virtually out of the question.

Stu Charlton’s blog was where I first saw those terms used, and I found them very enlightening. So did Bob Warfield.

One of the first things that attracted me to REST was the uniform interface constraint. Mark Baker first brought it to my attention nearly 8 years ago, and before I looked at it, I thought it was just a bad idea, like a totally generic doIt() interface, devoid of any meaningful semantics. But of course, there’s much more to it than that. The HTTP interface, for example, strikes a great balance that allows it to be efficiently reused across a very wide variety of applications. And when such a uniform interface is reused, the applications that use it stand a much better chance of being reusable themselves than if they were written against a non-uniform application-specific interface.

My latest Internet Computing column, entitled Serendipitous Reuse (and here’s the pdf if you prefer), explores how the uniform interface contributes to reuse of both the planned and serendipitous kinds.