- 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