By offering its web services both ways -- XML/HTTP and SOAP -- Amazon has set up a marvelous experiment.
6) Why do Amazon.com Web Services use both SOAP and XML over HTTP?
We wanted to provide a platform that would both address the different needs of different people and provide the opportunity to test the debate between two popular Web services standards. Some developers like working with pure XML; others prefer SOAP. We didn't want to force people to use a protocol they were not comfortable using. [ Amazon.com Web Services FAQ ]
I hope Amazon will report the results of this experiment. My own inclination is to prefer XML/HTTP for these simple kinds of queries. The RESTful approach strikes a nice balance between human- and machine-oriented uses of the API, and sets up some powerful network effects.
My wife's wrote a book this year, and she likes to keep an eye on its status. The raw Amazon XML results available at this URL aren't any easier to use than the book's Amazon home page . However, running that XML data through this XSLT transform yields a clean, simple result:
<?xml version="1.0" encoding="utf-8" ?> <amazonResult> <title>The Weekend Crafter: Rubber Stamp Carving</title> <author>Luann Udell</author> <salesRank>17,254</salesRank> <avgRating>5</avgRating> </amazonResult>
Incidentally, I had to remove this from the stylesheet:
<countOfReviews> <xsl:value-of select="count(Reviews/CustomerReview)"/> </countOfReviews>
To conserve bandwidth, Amazon apparently reports just the first three reviews, so the count was always 3. Since there's no CountOfReviews field either, I'm slightly disappointed. Monitoring changes in that count is something every author would like to do.
The interesting thing about this simple report is that it can serve a dual purpose. It's XML, but simple enough to be directly readable. Dressing it up with HTML formatting wouldn't really add anything. And by leaving it as XML, it's a result that can be pipelined with other RESTful operations.
Here's the complete URL to the report. It uses the W3C's public XSLT service, fetches the stylesheet from my Radio gems directory, and fetches the XML from Amazon. Because all three of these components have public URLs, anyone can use the combined URL, and can vary the Asin (ISBN) to check on different books. The resulting XML, again, can be recombined with other RESTful things.
My guess is that the majority of Amazon's web services access will follow this route. I hope this doesn't further polarize the REST/SOAP situation, though. The simple, query-oriented APIs that Google and now Amazon have offered are not really a fair test. Partner interfaces that require more complex two-way exchanges, whether in RPC format or document format, are the province of SOAP. These by their very nature are harder to make accessible to experimenters. So let's enjoy the RESTful aspect of Amazon without jumping to broad conclusions.
Postscript: I just read Dave Winer's plea for the Radio community to create an Amazon counterpart to system.verbs.apps.google. And I was reminded that I used GoogleBox all the time -- most recently, to update my homepage with the Google query "Amazon XML API." This is a major use case for SOAP. Even when queries are simple, raw XML machinery is of course way beyond most people. If a lot of people are using SOAP-aware software like Radio, then maybe SOAP will turn out to be the dominant mode of access to the Amazon APIs. I'm looking forward to the results of this experiment.
Former URL: http://weblog.infoworld.com/udell/2002/07/17.html#a341