2006-12-01: Novel, yes; widespread, no; Old news, new acronyms: REST vs. SOAP
Novel, yes; widespread, no
That's right, kids, November is over and while my novel isn't "done," it did
indeed pass 50000 words. I have a tiny bit of work left to completely wrap
up the story, and a little bit more tweaking before it's up to my usual
questionable quality standards (as opposed to its current "unquestionable"
quality). That should only take a few more days.
And after that, you, yes, you, the one and only, will still not have
access to read it, because I'm not currently planning to post it publicly
anywhere, lest Google reveal to all the world that I'm an idiot. But I'd
probably send you a private copy if you asked.
Old news, new acronyms: REST vs. SOAP
I've been seeing news in random places around the web lately announcing the
official death of Web Services and SOAP in favour of REST, or was it XML
Schemas in favour of RelaxNG, or whatever bad things the people in question
don't like in favour of whatever good things the people in question
do like. You can find many of these links by following links from Tim
And then comes the inevitable reply, They
Can't Hear You, explaining that these so-called "deaths" are rather
overstated, because all of the supposedly "bad" technologies are still very
much in use in big companies everywhere, and moreover, most people in those
companies haven't even heard of the so-called "good" technologies.
Now, of course I'm always totally in favour of a good
flamewar, but if the flamewar is good enough, then I prefer to confuse
the issue rather than resolving it. Thus, I bring you my considered
Yes, it seems those bad things really are dead. But they're not. Except
where they are.
You see, declaring SOAP dead in favour of REST is equivalent to declaring
Windows dead in favour of Unix. No, no, not "just as stupid." I mean
equivalent. If one was true, the other would probably also be true.
And you may have noticed that Unix has totally prevailed. But it hasn't.
Except in the places where it has.
A while ago at NITI I did a presentation
about functionality vs. elegance. Basically, I argued that people often
treat them as a single continuum, sacrificing features for beauty or vice
versa according to their priorities. But really they're two independent
dimensions, and a small few things are functional and elegant.
In my example at the time, I showed how Windows isn't elegant (well duh) but
it is highly functional; you can make it do anything. Unix,
on the other hand, was an amazing achievement in its heyday because it was
highly functional and highly elegant. Because this was originally
true, people experience the beauty of Unix and then tend to believe that
"the Unix way" is the best way to solve all their problems.
Unfortunately, original Unix was designed for processing text on a command
line. Its elegance came from clever, well-executed simplifications like the
unified filesystem, devices-as-files, pipelines, and everything-as-text.
Unfortunately, none of those things have anything to do with
graphical user interfaces. X11 is anything but elegant, and none of
the various Unix widget toolkits are earth-shatteringly great like Unix was.
Furthermore, trying to map elegant command-line stuff into GUIs has been a
consistent, horrible failure; compare a Windows-based IDE debugger to
any GUI wrapper on top of gdb, and just try to tell me I'm wrong.
To make something both highly functional and highly elegant, you need what
we call a simplifying assumption. In the command-line world, the
credit typically goes to the invention of Unix pipes, which let you easily
link small tools together to accomplish a big job. Windows has no such
magic (well it does, but they forgot to support it in the shell), and so it
predictably sucks at text processing. But Unix has no simplifying
assumption in its GUI. So they have to trade off between functionality
and elegance. In typical Unix fashion, this means there are a zillion
half-baked alternatives, each at different points along the tradeoff
But there are places where Unix's traditional elegance is still a win, and
that happens to be the world of Internet servers. The web works because it
mostly just paraphrases Unix's cleverness. It has a unified filesystem (er,
URI space), devices-as-files (er, CGI scripts generating content), and
everything-as-text (html). Sadly, its UI mostly sucks, except for the AJAX
it into a decent UI, at the cost of almost all the operational elegance.
That's because what's missing from the web model (and the Unix GUI, for that
matter) is an analogue for Unix's pipelines - I can't easily connect
one little thing to another little thing to generate a high-quality big
The fancy modern name for that is a component system. Unix pipelines
are one kind of component system, although people who talk about Component
Systems as if they had Capital Letters would probably gasp at my saying so.
That's because those people design the second kind of component system:
things like COM. You know: the way Windows does it.
So here's the thing. In the world of the web, there are two competing ideas
for component systems: REST and SOAP. And these correspond almost exactly
to Unix and Windows, or in other words, pipelines and COM. Pipelines
contain squishy (nowadays Web 2.0 people would say "mashable")
text in which the format is flexible and implicit and
probably being parsed only 99% correctly. That sounds to me exactly
like REST and microformats and RSS and friends.
Meanwhile, there's SOAP and SOA and WS-Whatever and XML Schemas. They're
just like COM: useless unless your syntax and semantics are exactly right,
semi-easily checkable for valid syntax, and purportedly self-describing in
an essentially useless way (except for syntax checking purposes).
Self-describing or not, Google will never be able to index your SOAP service
without a special plugin, just like Google Desktop can't index any of your
binary document formats without special COM plugins, one per format.
Phew. Okay, so that was the background information. Here's my point: yes,
the whole Internet runs on Unix philosophy. But businesses sure
don't. The big problem comes up in my description of pipelines up above:
they only parse about 99% correctly, which is fine for your idiotic comments
about YouTube videos, but pretty
nasty when you mangle critical business data. And when the business
dudes get involved, they'd rather do anything than mangle their
critical business data. You hear me? Anything!
If it keeps the data from getting mangled, they'd happily sacrifice
searchability. Or developer hours. Or the ability to use off-the-shelf
software. Or millions of dollars in licensing fees (because at least
they'll accurately know how many millions).
Pay attention, because that attitude is exactly why Windows is so strong,
why the vast majority of developers prefer to develop on Windows, and why
the vast majority of users prefer to use Windows. It may be gross, and
adding new features or libraries may be a lot like stabbing yourself
repeatedly with a fork (which, tragically, is not itself included in Win32),
but Windows works consistently. So does SOAP. But not Unix or
microformats or REST.
It would be awesome if someone could find a way to satisfy both camps (the
Internet people and the Enterprise people) at once. Then maybe one or the
other set of technologies could finally die. But I'm not counting on it.
Until then, one or the other technology is effectively dead, but
which one it is depends who you are.
Syndicated 2006-12-02 03:55:27 from apenwarr's log