REST vs SOAP

With all the debate about SOAP vs REST I thought it would be worth a few column inches pointing out the differences between the two.

REST is an architectural style. SOAP is a message format. With SOAP there is a well defined processing and extensibility model. The two are not directly comparable in my opinion. The confusions comes as both approaches (for lack of a better word) are used to deliver web services.

In the future I would hope to see both REST and SOAP being offered (as they are in our very own Amazon Web Services AWS), there are peculiar advantages for each approach.

There is the simplicity, of REST with its HTTP verbs allowing for simple querying of a distant resource, and the coming transactional model support in SOAP, that will allow for far more complicated activities via Web Services.

In fact using SOAP 1.2 many of the RESTful features people so love (e.g. URI interface) can be combined with a SOAP payload, I think this is the beginning of an beautiful friendship.

REST’s straight forward nature offers low barriers of entry into using web services, this has resulted in the typical take up being 80% skewed in favor of REST  implementations by our own AWS.

I tend to think of REST as an introduction to the world of web services, and introduction that’s mostly good enough, especially for now, but one where it may need to be combined with some of the heavy weight features being built into SOAP for future applications.

My advice is pick the best one for you, but keep an eye on both as I am certain they have a bright future together

Don

Comments

[pwb]

People always seem to write that REST is so much easier and works fine but that SOAP is good for some things but then never point out what these things are. REST seems to work fine for the vast, vast majority of what people are doing so why do I wnat to use SOAP?

[William Drury]

Same here. I have been parsing XML feeds from Amazon, SearchFeed, Gigablast, Google, FindWhat and many others for years, and in every case, REST was the way to do it. In fact, I had to look the acronym up, I was just calling it 'XML over HTTP'.

Granted, the Amazon feed is highly nested, highly variable, and can follow a number of different formats (even more, now that we can request Response Groups). Generally, this is the most complicated piece of the equation, and can be a frustrating, error-prone experience to parse correctly. But 4.0 has been out long enough that API modules like PERL's Net::Amazon and others should hide most of that complexity.

We're already using HTTP to deliver the results as HTML, why add another layer of complexity? REST works.