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

SOAP VS REST

[xyzzy]

REST WINS! FLAWLESS VICTORY!

REST or SOAP: yes

[jnana]

Just how do you submit a complex transactional XML document using REST? Parsing a URL query string with 200 name-value pairs, then assembling that back into the XML document that the recipient expects does not seem like a good solution. Surely, submitting a SOAP document that wraps the XML document is better in this case.

It is understandable that Amazon sees most people using REST. They're mostly hobbyists and amateur programmers, and REST is easier and sufficient for the very simple things that you can do via the Amazon web services api, but if one were trying to submit more information -- say a long purchase order -- the limitations of REST would be more apparent. The RPC style of SOAP is often better with REST, but for the document-exchange style, REST is inadequate.

Re:REST or SOAP: yes

[pmz]

They're mostly hobbyists and amateur programmers, and REST is easier and sufficient for the very simple things that you can do via the Amazon web services api, but if one were trying to submit more information -- say a long purchase order -- the limitations of REST would be more apparent.

I would bet there are significant numbers of professionals using REST, too. It has a pretty high usefulness threshold, because a lot of tasks don't require the complex hierarchical datasets allowed by XML.

I've personally used REST instead of SOAP in an internal project, because REST is simple to implement and totally adequate for what we were trying to do. SOAP would have required: learning, sorting through buzzwords, more learning, some more sorting, and a prototype before actually creating a working system. Basically, SOAP has a higher learning curve that can (and should) be avoided when possible. Also, the tools and libraries for SOAP are much younger than those for REST.

Re:REST or SOAP: yes

[peterdaly]

This webservice is not complicated enough for SOAP to be worth while.

Parsing a URL query string with 200 name-value pairs, then assembling that back into the XML document that the recipient expects does not seem like a good solution.

That does not describe Amazon's interface. There are a handful of parameters at most.

SOAP is not the best solution for all problems like this. In the Amazon case, REST may be better in some (many?) cases.

-Pete

Re:REST or SOAP: yes

[Fweeky]

REST is not mutually exclusive from PUTing or POSTing a complex XML document when necessary. SOAP, however, does make simple GET operations stupidly overcomplex and hard to cache.

Re:REST or SOAP: yes

[smallpaul]

You don't undestand what REST is. There is nothing about REST that disallows the posting of an XML document. The question is how you use URLs and HTTP verbs, not what syntax you use. You say that "surely submitting a SOAP document that wraps an XML document is..." There is no question that XML is the right choice in some cases. That's why REST and XML are so often used together. But if you're going to claim that there is some benefit in "wrapping" the XML in SOAP, you'll have to back it up. In my experience, the vast majority of people "wrap" XML in SOAP but don't have any reason for doing so other than buzzword compliance.

Re:REST or SOAP: yes

[Kopretinka]

Just how do you submit a complex transactional XML document using REST? Parsing a URL query string with 200 name-value pairs, then assembling that back into the XML document that the recipient expects does not seem like a good solution.

The above shows just how little jnana understands REST. Note that SOAP over HTTP uses POST and does not do any URL encoding of the requests. Just why can't a simple HTTP application do the same?

HTTP GET is to be used for retrieval only, and all URL encoding that may happen is only to identify the particular resource. In a well designed REST application no complex data structures need to go into the GET URL. For submissions to processing, there is the POST method.

The real difference between SOAP and REST is that currently the only protocol designed around REST is an application protocol for hypermedia transfer whereas SOAP is a general protocol upon which application protocols may be built, including RESTful ones. One of the protocols already built over SOAP is the RESTless RPC.

Disclosure: I'm a member of the W3C working group that's just now finishing SOAP 1.2.

Re:REST or SOAP: yes

[j7953]

Just how do you submit a complex transactional XML document using REST?

You can use HTTP POST with REST, so you simply POST the XML document to the appropriate URL (probably an URL that identifies some sort of handler).

Surely, submitting a SOAP document that wraps the XML document is better in this case.

But why do you want to wrap it?

The thing that is "wrong" about SOAP is that everything is wrapped into a POST request, even if you aren't posting anything but simply requesting some information.

For example, take the web service interface of some online store. I don't know Amazon's interface, but I suppose they would offer you a function to get the delivery status of your orders, and a way of sending them orders. With SOAP, if you want to send them an order, you'll have to wrap the order into a SOAP message call. With REST, you'd simply POST the order to an appropriate ressource, like http://webservice.example.com/newOrder. What an order looks like isn't defined by either SOAP or REST, so for the order itself, you'll have to build your own XML DTD (or schema or whatever) anyway. You'll also have to define a return type, obviously. In the SOAP case, that would be a SOAP message containing e.g. the order number. With REST, you could send back an application/xml response containing exactly the same data, but without the SOAP envelope.

What about getting the status of an order? With SOAP, you would POST the appropriate method call to some ressource. With REST, you could simply send a GET request without any parameters to an appropriate URL, e.g. http://webservice.example.com/order/1234567/status . Obviously the server would need to check if the order number is valid and if the client has the permission to request the status of that order. But the HTTP protocol already defines how to handle this, there are appropriate error codes. What do you need SOAP for?

There really isn't anything you can do with SOAP that you couldn't do with REST as well.

Personally, I think that REST is not only simpler, but the interface also feels much more "natural", i.e. it is more consistent with how URLs and HTTP are supposed to work. I guess the main thing I dislike about SOAP is that it doesn't really utilize the full potential of the HTTP standard, HTTP is only used as a wrapper. Obviously there are situations where you want this, after all it also adds some extra flexibility. But I believe in most cases where you want a "web service" you really want a web service, i.e. you want to use HTTP anyway.

Re:REST or SOAP: yes

[Kopretinka]

Oh yes, I forgot to mention that SOAP currently uses HTTP as the underlying transport protocol. By using POST only, it limits the usefulness of those resources to the rest of the HTTP World Wide Web.

That's why SOAP 1.2 tries to allow the use of other HTTP methods where appropriate, so that ideally services using SOAP 1.2 over HTTP will be fully-fledged HTTP resources and will fit into the Web world.

Re:REST or SOAP: yes

[oz_ko]

erhemm...

I think you will find that SOAP is transport agnostic - ie you could use it over SMTP in an email message.

HTTP post is only one of the methods of delivering a SOAP envelope.

In other news

[the_other_one]

Amazon patents the use of REST and SOAP...

Re:In other news

[KILNA]

In other other news, slashdot users were unaffected by the Amazon announcement due to caffein addiction and poor hygiene.

Why Amazon provides two interfaces

[darkpurpleblob]

From the FAQ:

Why does Amazon 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 an opportunity to further 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 weren't comfortable using.

That explains those annoying fake Amazon sites

[Anonymous Coward]

Amazon's web services have attracted a thriving community, people are making real money building alternate interfaces to Amazon. . . Cool.

It's not cool when you want to buy an item Amazon no longer stocks and you get hundreds of hits from this community, instead of real hits. To me it's just a way of tricking Google to send more people to Amazon. How many Amazon clones do we need?

How Amazon Web Services came about

[darkpurpleblob]

Tim O'Reilly played a integral part in getting the Amazon Web Services off the ground:

Jeff was intrigued, and told me a day or two later that he'd discovered that his skunkworks team already had a web services API in the works. But he says that without my presentation he "might have done something stupid like shutting the project down.

Read about the rest in Tim's weblog post.

XML over HTTP is where it's at

[peterdaly]

I developed www.bitworm.com (Computer Books) using the XML over http service. I have never used SOAP, and have never seen a reason to. With their server side XSL translations, I retieve custom responses designed to conserve bandwidth/response when combined with my caching backend. I don't think I can do that with SOAP.

SOAP is just too much work in the Amazon case with little ROI. XML is just as simple when used with JDom, or another simple parser.

(Smart) people will use the right tool for the job. In this case, XMLoverHTTP is a better solution than SOAP. I am glad to see I am not the only person who thinks SOAP just isn't worth the trouble.

-Pete

Yeah, but all the big players used soap

[Kagato]

Having worked with Amazon for one of Amazons largest online stores I can say SOAP is very much here to stay. Although many may use RIST, the big online partners use SOAP. Or rather Amazons implimentation of SOAP. With does some funky stuff with MIME attachments.

Still, once you get it worked out the process is actually pretty smooth. All my complaints are about how they use their data, not how it's transported.

I just switched from REST to SOAP

[Anonymous Coward]

Over the weekend, I rewrote parts of my site that use Amazon data to use SOAP, with the help of nuSoap for php. It's much cleaner code now, and it just seems to work better. I originally went with REST because it's what they first offered, and I was just too lazy to update the code until now.

MIME-RPC as an alternative to SOAP and XML-RPC

[cpeterso]

A quiet alternative is MIME-RPC .

MIME-RPC is a protocol for applications written in different languages and on different platforms to communicate with each other using a public standards:

• It works with the millions of already deployed web apps and web browsers (without plugins)
  
• It handles all Internet data including Unicode, JPEG, XML, etc.
  
• It works over both HTTP and SMTP (web and email)
  
• It protects application programmers from wire level concerns.
  
• It provides complete interlanguage object serialization (cyclic refs.) as well as interlanguage messaging
  
• It supports two way communication over client/server connections
  
• It is easy to implement.
  
• It doesn't require an extra XML parser when your application doesn't need one.
  
• Its specification is short and unambiguous.
  
• It leverages existing transport layer features like encryption, proxying, asynchrony, streaming/chunking, etc.
  

Notes on SOAP vs MIME-RPC:

• SOAP does not interoperate with existing browser based apps. MIME-RPC does.
  
• SOAP does not do generic object serialization
  
• SOAP forces the programmer to think about type coercion because it hides foreign data as base64encoded rather than labeling it with a useful type.
  
• SOAP does not handle delivery of XML or other types well. MIME-RPC does.
  
• The SOAP with attachments spec basically says to use MIME. If you are doing that, you might as well use MIME for everything (and therefore MIME-RPC).
  
• The SOAP with attachments spec is ambiguous about the type of attached objects. Should the type be interpreted according to its mime content-type or according to some XML schema? MIME-RPC provides an unambiguous interpretation.
  
• SOAP constrains method and variable names to be consistent with XML tag names. Many languages (e.g. SQL) allow method and parameter names that are not permitted in XML tags.
  
• MIME-RPC is much easier to implement correctly than SOAP
  
• MIME-RPC has less processing overhead than SOAP.
  
  

Re:MIME-RPC as an alternative to SOAP and XML-RPC

[Anonymous Coward]

Maybe if they get it IETF standardized, and drop the trademark claim.

Is it Evil?

[stagmeister]

The question is, does Amazon's REST take into account the Evil Bit? Remember, if you're evil we need to wash your mouth out with SOAP!

Well duh!

[bartok]

Geeks prefer to rest than to use soap.

*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

Use some helper code

[bill_mcgonigle]

I have a system that uses XML/RPC but it could have just as easily been SOAP or REST and it wouldn't make a difference. I have a data structure in Java that gets put through some helper classes, then on the server side, I have a response that feeds into a module, and I get out a data structure. So, I never actually see any XML/RPC, but I still have the advantages of the interoperability of the standard. Moral: if you're doing much with any of these protocols your code could use some more abstraction.

Re:Use some helper code

[tcopeland]

This is so true. Your client code should look something like:

Client client = new XMLRPCClient("host", "userid", "passwd");
client.doStuff();

Abstract all the underlying protocol stuff behind that Client interface and your code will be much easier to read and understand...

Tom

good use of soap

[Horny Smurf]

Kathleen could almost smell the sharpness of ozone as the sudden
cacophony woke her from a glowing dreamscape. In the disturbed dream
she had been approaching a girl in diaphanous white, slowly walking
towards a raised marble dais. She'd been whispering unknown syllables,
the sounds falling rhythmically between her parted lips, passing
through heady incense, and mingling with the gentle singing voices
surrounding her. The quiet rhythms of the haunting dream melody had
shattered into a million shards, like a mirror broken from the sudden
force of a hammered fist.

She was conscious of the next strike before she had fully awakened,
its luminosity lighting her retinas through the blinds and her closed
eyelids. The subsequent crashing was immediate and close, shaking her
lungs and rattling the bed in which she lay.

She curled up, drawing the covers under her chin and softly whimpered.
She opened her eyes again, dreading the next strike, hoping that the
thunder would move away and leave her alone. She wasn't alone. His
face on the pillow beside her, softly illuminated by the dim light
from the window, was strong and relaxed in sleep. She looked at him
with envy, wondering how he could sleep through the storm and wishing
she could rejoin him in dreamscape. She reached out tentatively and
traced his cheek with one slender finger. He murmured and rolled over
at the touch, not waking.

Another strike, not as close, rumbled through the darkness. She jumped
at the flash and then again with the thunder moments later. Kathleen
swallowed, suddenly thirsty. Her heart reverberated a dull rhythm in
her ears.

Lifting the sheets damp with her perspiration, she swung her bare legs
from the bed and sat up. Another flash illuminated the room like an
eerie strobe. She cried out as the thunder washed over her, but her
small sounds were no match for the power of the storm. Her tiny cries
were the squeak of a mouse fighting the mighty roar of a wolf.

As she rose to her bare feet, the rain began to tumble to the earth,
released in a torrent of tears from the heavens above. Even through
the insulation of the attic, she could hear the staccato beat of the
rain against the shingles. She looked at the stippled ceiling above
her and silently thanked a higher power that she had a roof over her
head, and that she was warm and dry. Despite her protection from the
elements, she shivered. She hugged herself as she walked carefully out
of the room, leaving the prone man sleeping, blissfully unaware of the
storm or her distress. Her bare feet whispered across the hardwood and
down the flight of steps to the main level of the house.

She poured a tall glass of milk in the dim glow of the refrigerator
lamp. Sitting at the kitchen table in the dark, she could hear the
rain whipping into the glass of the windows. She cringed as something
heavy began to hit the house, the new beat low and dangerous.

She tightened, lowering her head to the table, her heart racing, her
stomach in knots. Tears threatened and spilled as another bolt of
light streaked across the sky, its roar carried and simultaneously
shattered by the wind.

She wanted to call for her father. Her father would protect her, stop
the storm, stop her fright, stroke her hair ever so gently until it
ended, infinitely patient with her. Her sisters had always made fun of
her, taunting her. Their voices echoed through her memory.

"Baby. Baby. Afraid of the thunder. Grow up little baby." She could
still hear their singsong voices tormenting her through the
intervening years.

Her father, long gone now, chastised the imps who couldn't possibly
understand, but it had only stopped them while in his presence.
Engulfing her small hand in his own, her father lead her to the
window, parting the curtains, showing her the storm, forcing her to
confront it, forcing her to confront herself, gently

vuja de

[Anonymous Coward]

Whatta coincidence. My boss just complained that I rest too much and smell like I don't use soap.

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?

wow - so many standards

[Anonymous Coward]

SOAP
REST
XML-RPC
MIME-RPC

The great thing about standards is that there are so many to choose from ;-)

Seriously, though, these are all just instances of two programs exchanging text. The text is just formatted differently in each case.

People have been writing these text-transfer protocols for decades. The "benefit" of the current situation is that everybody gets to define their own standard and put a nifty name on it, then hype it around the industry to sell books.