The Great REST vs SOAP Debate

posted Thursday, November 16, 2006 10:55 PM

If you've done any work designing SOAP based web services you undoubtedly know that that The S stands for Simple, right? 

As someone who has been working extensively with SOAP based web services (developed using Indigo) over the last year+, I have a lot of interest in the REST approach.  I've found the following "REST Dialogue" posts useful, and I'm definitely looking forward to checking out Leonard Richardson and Sam Ruby, "REST Web Services" book!  Where do you stand on the REST vs SOAP debate?

The REST Dialogues

 

Technorati tags: , , , ,
10 Comments

# re: The Great REST vs SOAP Debate

Friday, November 17, 2006 8:04 AM by Sam Gentile    
Oh, no, not yoo too-). Don't go there, it's a red herring. Its not SOAP vs. REST. You can still design REST-style APIs with SOAP as Peter Drayton and I did at Groove. Moreover, HTTP and REST are hugely limited. Think about it, no other protocols, no WS-*, no reliable sessions, etc. etc. etc. Not many enterprise apps (no not Amazon or Google) can be built on just HTTP.

# re: The Great REST vs SOAP Debate

Friday, November 17, 2006 10:07 PM by Alex James    
REST is like SQL in my mind, at least the verbs are. If more of our services/data were exposed restfully could we not create a general purpose language to consume and integrate? RESTQL???

# re: The Great REST vs SOAP Debate

Saturday, November 18, 2006 8:01 AM by Steve    
Hey Sam,
I agree that RESTful API's aren't the be all and end all. They have some known limitations, such as only being available over HTTP, and certainly aren't the right fit for everything. I do think that can fit the need in a number of scenarios, such the scenarios that most of the publicly available services from Yahoo, Amazon, Google, and etc. are targeted at.

As you pointed out, if you need WS-* and etc then REST probably isn't for you. With all this said I feel like I don't understand nearly enough about the specifics of designing REST services, which is why I'm looking forward to Sam Ruby's REST Web Services book.

Thanks for the comments!

# re: The Great REST vs SOAP Debate

Saturday, November 18, 2006 8:06 AM by Steve    
Hey Alex, RESTQL sounds a lot like what is coming in the next version of Ruby on Rails (or maybe it's already out?). I haven't read too much on it but I saw a presentation by DHH (the Rails dude) which talked a lot about the ideas of having a query language (via URI's) that seems similar to "RESTQL" :)

I'm not sure if this is the best place to look for details of the REST support in Rails but it's the one Google pointed me to:

http://www.xml.com/pub/a/2005/11/02/rest-on-rails.html

# re: The Great REST vs SOAP Debate

Sunday, November 19, 2006 12:04 AM by sAM gENTILE    
A non idempotent message: Withdraw $100 Billion. Easily mapped to REST.
An idempotent message: If transaction #X has not been processed, withdraw $100 Billion as transaction #X. How do you express that REST-fully?


# re: The Great REST vs SOAP Debate

Sunday, November 19, 2006 9:14 AM by Steve    
You ask someone who knows what they're doing when it comes to REST, which is clearly not me :)

I assume you would provide details on the REST URI which specified the details. Something like:

http://samlovesrest.com/withdraw/100B/?tid=X

But like I said, I don't really know all that much about how best to design anything REST'fully.

# re: The Great REST vs SOAP Debate

Sunday, November 19, 2006 9:57 AM by sAM gENTILE    
No, you can't because its idempotent and transactional - requires state.

# re: The Great REST vs SOAP Debate

Sunday, November 19, 2006 7:08 PM by Steve    
What about it requires state?

# re: The Great REST vs SOAP Debate

Monday, November 20, 2006 3:14 PM by Sam Gentile    
One of the important design principles of service orientation is that the service should be made idempotent. Idempotent means 'it is okay if the requests arrive multiple times'. As a designer of the service, you should expect the messages to be delivered more than once and you should process the message only once.


# re: The Great REST vs SOAP Debate

Wednesday, November 22, 2006 4:02 PM by Mark Baker    
I'd just POST the amount to a resource that does the withdrawl/transfer, and let the server take care of applying it. POE (http://www.mnot.net/blog/2005/03/21/poe) could be used to provide only-once semantics.

BTW, that's the first I've heard about SOA services being idempotent. I think you must mean "reliable", not idempotent, since clearly you don't want every kind of message to have the same effect no matter how many times you send it. What if I really want to order two pizzas and didn't just hit the button twice accidentally? That said, if you can do something idempotently, you should probably try.

Post a Comment

 
 
Prove you're not a spammer: 
9 + 8 =