Web Services discussion worth watching
Posted 25 Apr 2002 at 17:15 UTC by simonstl
If you've been doing any work with SOAP/WSDL/UDDI, .NET, or related "Web
Services" goodies, you may want to take a close look at an intense and often angry
these technologies are
a threat to the
There is a wide range of issues, often mixing questions about patents with questions of technological
acceptance, and political questions about
vendors, open source, and the W3C.
As SOAP and Web Services percolate into open source projects like
Mono, the various Apache implementations, and a variety of other tools,
it may be a good idea to take a close look at the underpinnings of the
technology, not just whether it feels good today. Distributed services
have always been complex, and it's not clear that SOAP has cleaned away
the long-term complexity.
Developers who focus on Web-related projects may also want to keep a
close eye on the W3C. Whether or not
the W3C stands up to member claims that Web Services are its work
may have a substantial impact on the shape and perhaps the cost of the Web.
If, on the other hand, you just care about whether things mostly work
today, you can find plenty of comfort from a variety of "everybody's
doing it" arguments. (1
Here's why web services is a really bad idea
One of the main advantages of web services is that your data storage will be on the service provider's server. That way you can access
your application from anywhere.
But it also means that if the service provider goes out of business, or decides your critical application is no longer profitable, you're
The photo and remote backup hosting providers have so far escaped liability, so I imagine the providers for critical services will too. And
anyway, provider liability is not what you want - it's your data back, which so far many people have been unable to get.
Loss of data stored on hosting provider's servers is already happened. It's a reality. It will only get many times worse when Web
Imagine that it's not the only copies of your photos of your dead brother that you lose, but the payroll history for a medium sized
I will have more to say on this topic.
i'm only guessing. Does this discussion have anything to do with that
annoying "ad.doubleclick.net not found" message?
I imagine that simonstl can only be depressed by the
first two responses to his article, and may be seriously reconsidering
the value of his participation at Advogato.
C'mon, people... Get with the program.
I suppose there is a significant faction here that will not or cannot
do Deep Architectural Thinking about big systems like the Web. (I knew
they were here; I just didn't expect them to be quite so vocal about
To boil the Web Services conflict down to one of pragmatism versus
idealism is perhaps somewhat unjust, but not entirely, IMO. The REST
camp suffers from the same problem that plagues the Semantic Web camp
(though not to the same degree): a failure to present their ideas in a
way that is accessible to The Average Web Developer. Part of the reason
people understand SOAP (or at least think they do, which is
arguably more important) is precisely because it
doesn't have all the philosophical and intellectual
baggage that is needed to justify the constraints present in approaches
like REST. Valid or not, the relevance of these constraints is only as
great as the number of people who understand why they're there.
At this point we are stuck with SOAP for a while, for better or
worse. Those who prefer a different approach should let SOAP go its own
way, and make it part of their job to ensure that the SOAP camp is
equally accommodating to alternate approaches. And the REST folks should
take this experience to heart: this is what happens when, in pursuit of
lofty goals, you lose touch with the needs of the average developer.
Keeping him happy is key to the realization of those goals.
The first two replies weren't so bad - "Web Services" still means a lot
of different things to different people.
As far as the pragmatism vs. idealism angle, there's a lot more depth to
this than "REST is aesthetically more pleasing and SOAP appeals to the
average Web developer."
REST _is_ what most Web developers do every day, without really
pondering it that hard. I don't see anyone building Web sites, for
instance, that use a single URI and expect users to send POST requests
to get back different pages. (I may have to build one now, just to be
As stupid as that sounds on its face, that's precisely what SOAP does
for program-to-program communication. I don't mind request-response for
developers - I just want it done in a context that makes more sense.
that could mean switching to a different framework, like BEEP, or it could mean considering how
this works within the framework of the Web, and that's probably REST.
I'm happy to see SOAP go its own way. I'd just like it to:
stop calling itself "Web Services", since it ain't
find a different transport mechanism. Microsoft's proposed DIME
Find an appropriate home for the specs, and let the W3C focus on the
Clarify the intellectual property issues around SOAP itself, WSDL,
and UDDI, so average developers know what they'll be paying for
That last one seems well-covered in patent issues. Even
if you don't like REST, it may be the freest option.
Selling REST, posted 26 Apr 2002 at 15:58 UTC by braden »
I guess I was excessively cranky starting my last response. Still,
it's not like you, simonstl, haven't provided context
for the points you're making. Of course the term "Web Services" is
deliberately vague/misleading because it gives the marketers the
greatest leeway in their... ahem... projection of the concept's potential.
REST may be what most developers are doing now, but that's a matter
of technical convenience rather than ideological following. Where a
SOAP-style approach is more convenient to implement, it will win.
What factors might make the SOAP approach more convenient to
implement? How can the W3C make it a more attractive proposition for
implementors to stick to the REST model? Have any vendors made a
commitment to support the REST model with REST-friendly tools? I bet the
answer is "no".
If REST is to succeed as a dominant Web design philosophy (rather
than just another way to go about doing things), get Sun on board.
Alienated from the WSI, they may find the prospect of a Better Way
attractive. Sun needs an acronym (from somewhere other than Microsoft)
to demonstrate to the trade rags that they are serious about playing in
the same space as the WSI; REST needs tool support that validates its
Your questions about selling REST are well-taken, but there's some
serious irony to them.
REST isn't a "thing" in the same way that SOAP is or even BEEP is. SOAP
is an explicitly specified protocol framework that has XYZ processors
for XYZ environments. These toolkits are labeled "SOAP" or "Web
REST is pretty much riding on existing Web practice to get work done,
not an explicitly specified new-and-different framework. There are
hundreds, probably thousands, of REST toolkits out there, but they have
names like the Apache HTTP Server, Java XML data binding, XML::Parser,
Asking people and vendors to support REST is kind of like asking people
to support air. We all breathe it all the time, and sometimes do other
things with it. I see SOAP as polluting that air, but a lot of people
don't mind smog as long as they can drive their SUV to the mall.
I suppose it's possible to create toolkits around these things, but it's
pretty much development-by-accumulation, rather than coming up with new
conglomerations to market and heck, maybe patent.
Would you like some oxygen with that nitrogen?
I realize the relationship of REST to existing practice. But of the
tools you mention, how many can be used to subvert the REST philosophy
as well as implement it? It seems to me like such subversion could occur
relatively easily, and thus naively. What I'm getting at is that REST
proponents need to find a way of highlighting those practices that are
REST-kosher, and those than aren't. And then see to it that the tools
make it easy to do the Right Thing, or at least difficult to do the
did a talk "Global Computing: Some Questions for FOOLs".
I can almost guess what he is
with his pie
The REST camp suffers from the same problem that
plagues the Semantic Web camp (though not to the same
degree): a failure to present their ideas in a way that is accessible
to The Average Web Developer.
It's funny you say this, because just this week I gave a talk and
write a paper trying to solve this problem. It's called The Semantic Web (for
Web Developers). I'd appreciate your feedback.
Meanwhile, I agree that we need tools to make writing REST code
easier. I know that mnot and
amk are working on some.
As someone who's been watching "Web" services evolve in the background
for a while (my experience with XML/HTML is mostly in the document
rather than data areas), this was an interesting read.
My feeling, after reading all this (and thinking I have a pretty good
handle on it) is from the point of view of a content creator, REST is
the better solution. I believe you're right when you say it's what we've
been doing all along. Having only passing knowledge of SOAP-RPC, I was
surprised to learn it has a single URI interface to everything - I
thought it was just a formalization of some data structures in XML, but
apparently it's also a new "HTTP" interface that neglects unique URIs,
which I think is anathema to the structure of the web as it is now.
Upon reading the above paragraph, I find it extremely trite, since
obviously this was your point all along. But I guess it might be good
for me to say that as a "user" rather than "developer" of these things,
I prefer the REST approach over the SOAP one.
(I also think it's hardly an idealism v. pragmatism issue; in fact, I
think this really isn't much of a factor at all, except that ideally
technologies are perfect, and practically they often end up not being
so. What's "easier to implement" doesn't seem to be an issue here, since
REST doesn't need to be implemented per se.)
REST tools, posted 28 Apr 2002 at 04:58 UTC by piman »
, it seems most REST tools can easily be used to
"subvert" REST, in the sense that REST is still XML, as is SOAP. REST
doesn't seem to need much more than a web browser, web server, and XML
parser/generator. SOAP needs all that, plus the SOAP layer. IMO, it's
already difficult to DTWT, since it requires an additional layer of
software. The problem is more many programmers are looking at HTTP + XML
and thinking "Wow, this provides a nicer layer of data transfer
abstraction", then looking at SOAP and going "Another layer of
abstraction can't hurt", when in reality since no more semantical data
is actually contained in SOAP than REST interfaces, the layer of
abstraction only hurts (and damages the web infrastructure via poor URI
handling in the process).
My 0.02p, posted 29 Apr 2002 at 08:47 UTC by TheCorruptor »
Well, I'd have to agree with
for once; I'd rather see Google and Amazon offer these interfaces -
- regardless of implementation method in the short-term, than not
have them at all...
From my experience it's been tricky to dodge the SOAP bus,
not only because of the platforms we're deploying on, but due to
the Microsoft press that our local PHBs have been buying into. It's
an unintuitive framework in many senses, and seems overly
verbose for some of the uses we've been toying with in recent
months. However, technical arguments don't always win with
marketing pushes... ;-)
The larger problem from my perspective is trying to pick a
solution for both in and out-going feeds that is consistent accross
the board, supports our client's needs, yet remains "clean" in
implementation (for argued values of "clean"). Given our client's
tendancy to not be fond of XML in the first place, and that they are
often running legacy systems, I am at least lucky in the short-term;
we're pretty much working with a REST philosphy here atm, yet I
have the breathing space to look around and follow the arguments
whilst keeping my eye on our future direction. Somehow, given the
type of clients we have, I think that future direction will be
dominated by SOAP.
I am however, desperate to see some concensus of opinion
thoughts echo much of what I, and many of my collegues have
been feeling for a while, but I'm not too sure I'd like to see XML/
Web services develop outside the W3C either. That's a beast that
won't be tamed when it's wild. However, if it's in the zoo...?!
At least with traditional HTTP I know *all* our clients will be
able to integrate with their existing systems in some shape or
other, and that's enough of a reason to watch the discussion for a
while longer IMO.