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

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.

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.

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.