Lists Home |
Date Index |
4/25/2002 4:23:08 PM, "Bullard, Claude L (Len)" <firstname.lastname@example.org> wrote:
> REST requires discipline. SOAP requires
>a toolkit. How do you think a VB programmer will vote?
That is an EXTREMELY good point (not to mention one of
Len's trademark nice turns of phrase).
Joel Sapolsky has the most interesting pro-SOAP
commentary that I've seen yet, and he makes it clear
that It's the Visual GUI, Stupid.
"The claim that SOAP is bad because the wire format is
ugly and hard is like claiming nobody should use
Pentiums because their instruction sets are so much more
complicated than the instruction set for the 8086.
Yeah, it's true, but we have compilers that take
care of that..."
If this really is all there is to the SOAP vs REST
issue, Sapolsky (and Winer, et al.) are right.
But "ugliness" isn't what Baker, Prescod, et al.
are "grumping" about, it's reliability, scalability,
distributability, etc. He seems to miss the argument
that all that convenience only actually works if
everyone buys new routers, firewalls, caches,
etc. to make it work ... and there is no compelling
proof that all this new stuff can be designed,
built, and deployed in an economically feasible
manner by real companies. REST's
foundation argument is that you don't need a leap
of faith or a new SOAP Infrastructure Bubble to
believe that REST works, since the Web is
[Also, I'm out of my depth here, but the Pentium
example is actually an argument for elegance in
design; isn't the complicated x86 hardware being
emulated on a RISC chip in a modern Pentium? ]
>Don't turn off your brains. Turn them on long
>enough to admit that SOAP and REST are two
>different architectures, two different information
>ecosystems nesting in the same medium: the Internet.
That's exactly the issue. SOAP-RPC advocates (or
at least the pundits and columnists) imply that SOAP-RPC
will be able to leverage the Web infrastructure (HTTP
servers, firewalls, etc.). The REST people are saying
"not so fast", you're really creating new, fragmented
webs of SOAP endpoints / WSDL ports / whatever rather
than the Web of URIs that brought us where we are today.
This *may* work better someday (see Don Box's arguments
about preferring SOAP-aware caches and routers), but it's
about where the Web was in 1992.
>XML Doesn't Care about URIs or REST. That's
>why it will be the survivor. Now is when
>I'm glad markup won the bracket wars. When the
>swords turn back into plowshares, it will still
Don't be so sure. SOAP doesn't care about angle brackets;
1.2 is based on the InfoSet. Just as the WS-* vision abstracts
away HTTP and URIs so that they can be replaced with something
new and better, it abstracts away XML syntax, and could replace
it with a binary format, C# object declaration syntax, or
anything else that can be parsed into an InfoSet. XML as we
know it may find itself in the Dumpster along with HTTP and
URIs before long ... Maybe this is just my paranoia, nevertheless
Machiavelli looks like a bumbling amateur compared to some of
the people who are thinking long and hard about using WS-*
to re-write the rules of the Internet game.