REST vs. SOAP In Amazon Web Services

tadghin writes "I was recently talking with Jeff Barr, creator of syndic8 and now Amazon's chief web services evangelist. He let drop an interesting tidbit. Amazon has both SOAP and REST interfaces to their web services, and 85% of their usage is of the REST interface." Read on for some more thoughts and information on REST and Web services, including information about a free Web services seminar on April 22nd. " Despite all of the corporate hype over the SOAP stack, this is pretty compelling evidence that developers like the simpler REST approach. (I'm sure there are 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.)

Amazon's web services have attracted a thriving community, people are making real money building alternate interfaces to Amazon and collecting Associates commissions on the resulting sales, and there are even tool developers who have come up with the creative business model of agreeing with their users to have some percentage of the transactions use the tool developer's Associates id rather than the site owner's. Cool.

Amazon is holding a free all day web services workshop on April 22 at the O'Reilly Emerging Technologies Conference. The event is open to people not registered at the conference (though space is limited to 50 people).

P.S. Slashdot really ought to have web services as a topic area! Despite being over-hyped, this is a really important area, and there's a lot cooking. Amazon's web services"

Comments

*BSD is dying

[Anonymous Coward]

It is official; Netcraft now confirms: *BSD is dying

One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.

Let's keep to the facts and look at the numbers.

OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.

Fact: *BSD is dying

Where do xCBL and cXML fit in?

[sonamchauhan]

Can someone enlighten me how the usage (described below) of two Ecommerce dialects -- CommerceOne's xCBL and Ariba's cXML -- is classified?

I don't think the usage below can be classified as either Web Service, XML-RPC, SOAP, or REST. However, this usage comprises the majority of XML-based Ecommerce transactions I see in mainstream business these days (I work for a large office supplies company).

"The Usage"
-----------------
A business procedure (say, "place a purchase order") is executed by a simple transfer of an XML document. This XML document conforms to the standard it follows -- i.e. it is valid XML according to the standard's DTD/schema for that particular transaction.

For example, to send an XML purchase order via HTTP POST, the buyer would do the following sort of POST (HTTP protocol approximated below):

HTTP POST....
Content-Type: text/xml

<PurchaseOrder>
<Blah....

Note: the content type is "text-xml". There are no CGI params -- the XML document itself comprises the body of the HTTP POST. The seller sends back a synchronous response document (same TCP connection as the POST, but reverse direction). This 'sync response' must carry an HTTP 200 response header, but can also carry an XML document (this depends on the standard).

HTTP 200/OK
Content-Type: text/xml

<ConfirmationOfPurchaseOrder>
<Blah....

The submitter party processes this response.

Note, there are no standardised 'sections' of XML in the document (like there are with SOAP or Web-Services (unsure?) ). Also, unlike REST, there is no usage of other HTTP methods - DELETE, GET, etc -- only POST. The XML document itself specifies the procedure being carried out (a richer, and hence better, approach).

For example, to do an order cancellantion, another XML document is POST-ed.

HTTP POST....
Content-Type: text/xml

<PurchaseOrderCancellation>
<OrderReference attrib="blah">
<Blah....

So, does this sort of usage have a name (besides the name of the business standard)? What advantages do other approaches like Web Services bring to the table?