W3C home > Mailing lists > Public > www-tag@w3.org > April 2003

Re: amazon: rest and soap

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
Message-ID: <OFADEFAF54.AC7BE6DD-ON85256D01.00509A40@lotus.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:17 GMT