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

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.

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.

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: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.