- From: <noah_mendelsohn@us.ibm.com>
- Date: Mon, 7 Apr 2003 11:07:41 -0400
- To: Chris Lilley <chris@w3.org>
- Cc: www-tag@w3.org, tim@oreilly.com
Chris Lilley quotes Tim O'Reilly:
>> Despite all of the corporate hype over the SOAP
>> stack, this is pretty compelling evidence that
>> developers like the simpler REST approach.
It is? I think it's pretty compelling evidence that a set of
early-adopter developers found REST/XML more suitable to their current
needs, and that is indeed interesting. I'm not sure it says very much
beyond that, and even as someone who thinks SOAP is important, I don't
find this traffic report surprising. First of all, SOAP depends on an
infrastructure that is just turning the corner in terms of truly
widespread deployment. I'm sure that had Google deployed the
corresponding interfaces a number of years ago, we would have found that
Gopher, ftp, telnet or email interfaces would have generated more search
traffic than REST, because the infrastructure to do HTTP/XML was mainly in
the hands of early adopters. I just don't think we know what the balance
will be for various developers as we move forward. The early traffic
reports are, of course, interesting and significant within limits. I'm
not sure 15% is a very low number given the relative penetration of Web
and SOAP infrastructure to date. Of course, 85% user adoption should
never be ignored.
>> (I know there are many more complex applications
>> where SOAP is better, ...
Agreed.
>> ...but I've always liked technologies that have
>> low barriers to entry and grassroots adoption,
Me too.
>> and simple XML over HTTP approach seems to have that
>> winning combination.)
Certainly for some adopters today...why make generalizations beyond that?
I think one of the more interesting questions over time is: will
developers be better served by an HTTP GET returning application/xml or
application/soap+xml (I.e. RESTful SOAP vs. RESTful plain XML)? After
all, the minimal SOAP envelope wraps that same response in two boilerplate
elements, but those give you lots of important hooks for future
"evolveability", and a more clearly defined processing model at the
receiver.
My guess is: for straight low end machine processing of queries, you
might argue for simple application/xml, but I'd claim that for many
developers application/soap+xml hits a better sweet spot over time. If
Google were to offer a WSDL description for their application/soap+xml,
then pretty soon those developers would find lots of code that makes it
easy and robust to bind the search results into their programming
environment. SOAP's headers, and especially mustUnderstand headers will
make it easier for Google to add optional features to their responses over
time, and lots of middleware would make it easier to interpret those
headers. If Google wants to protect the privacy of search results (or
search strings), then WS Security over SOAP is likely to provide the
enabling infrastructure that's needed. So, application/soap+xml gives you
most of the simplicity of Google-invented XML, but with (probably) better
tool support, language bindings and better evolvability over time.
The interesting comparison is not just REST vs. SOAP, but REST alone vs.
RESTful SOAP (which, as you know, is supported by SOAP 1.2.) It doesn't
seem to me that the anecdotal reports of early traffic on Google settle
the question one way or the other. It may well be that the conclusion is
correct, and that over time plain XML will see better adoption than SOAP
over REST (or non-RESTful SOAP). I just don't think this report justifies
a conclusion one way or the other. I'd love to see Google deploy a
RESTful SOAP interface, supporting HTTP get, as SOAP 1.2 infrastructure
becomes more prevalent.
------------------------------------------------------------------
Noah Mendelsohn Voice: 1-617-693-4036
IBM Corporation Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------
Chris Lilley <chris@w3.org>
Sent by: www-tag-request@w3.org
04/05/2003 09:15 AM
Please respond to Chris Lilley
To: www-tag@w3.org
cc: (bcc: Noah Mendelsohn/Cambridge/IBM)
Subject: amazon: rest and soap
Hello www-tag,
Article by Tim O'Reilly makes interesting reading.
> Amazon has both SOAP and REST interfaces to their web services, and
> 85% of their usage is of the REST interface. Despite all of the
> corporate hype over the SOAP stack, this is pretty compelling
> evidence that developers like the simpler REST approach. (I know
> there are many more complex applications where SOAP is better, but
> I've always liked technologies that have low barriers to entry and
> grassroots adoption, and simple XML over HTTP approach seems to have
> that winning combination.)
http://www.oreillynet.com/pub/wlg/3005
from the license agreement I can confirm that they offer both
approaches:
>> Amazon.com Web Services is a platform to publish and invoke
>> applications that perform various functions, such as retrieving
>> information about Amazon.com products or adding a product to an
>> Amazon.com shopping cart, wish list, or registry. Amazon.com Web
>> Services can be accessed through two interfaces: XML over HTTP or
>> SOAP. Both of these methods return "structured data" (product name,
>> manufacturer, price, etc.) about products available at
>> www.amazon.com and www.amazon.co.uk (together, the "Amazon.com
>> Website") based on parameters such as keyword search terms and
>> browse tree nodes.
http://associates.amazon.com/exec/panama/associates/join/developer/kit.html
clearly I can't confirm what proportion of developers use which
interface, or why.
--
Chris mailto:chris@w3.org
Received on Monday, 7 April 2003 11:14:31 UTC