Trends: REST to over take SOAP?
Not too long ago I took a class for developing web services. The content of the class focused almost exclusively on developing SOAP based web services. While there is nothing particularly difficult about SOAP, it seemed to require a lot of steps; defining your data elements, creating a wsdl, and all the tools you had to use. While having a contract can be beneficial when the web service will be facing external clients, it seemed to be a lot of steps to go through to get a web service going and also heavy-weight.
Near the end of the class we briefly went over the RESTful web service philosophy. REST seemed, to me, to be a lot easier to use as it didn't require nearly as much setup, and it utilized the pre-existing http protocols (GET, POST, PUT, DELETE). Also with XML going only one way, a well designed RESTful web service should be faster than its SOAP counter part. The internet is a big place so there is plenty of room for both philosophies, but given RESTful's smaller learning curve and being seen as the "trendy" choice, I can see it continuing to increase in popularity, particularly among younger developers. Anyways I decided to do a some research on the subject and wanted to share what I have found.
http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest - An excellent article that gives a very good description of the two philosophies and their respective pros and cons. “Part 2” covers WSDL vs. WADL, which is also a really good read.
http://blogs.oracle.com/SOAandEDA/2009/04/soap_or_rest_its_about_your_pr.html – Horror of horrors, this article suggest to focus on business needs instead of technology.
No related posts.

November 4th, 2009 - 10:58
You are going to find that SOAP is very prevalent because all the Microsoft tools and Java tools make generating SOAP web services trivial. With ASP.NET Web Services, you don’t have to write a WSDL, write the actual soap messages or do anything in XML, its all done in code.
Where SOAP really starts to be painful is when you are writing systems in Python, Ruby, PHP, etc where these automatic and abstractions aren’t as prevalent. REST is easier to program against when you have to actually write the code.
November 4th, 2009 - 12:06
I was at the microsoft techdays conference and they had a talk about RESTful services. In the lecture they mentioned that as of right now MS is not making any advances with SOAP, but has added all kinds of support for REST.
One of the points they were driving about SOAP was that because a service specifies the HTTP verb, instead of just using POST like SOAP does, GET requests can be cached.
November 4th, 2009 - 12:46
The only SOAP API I have used and come to appreciate is Spring’s API. Spring doesn’t deal with all of that automagic generation bullcrap that most other APIs use. It’s contract first; you define your XML schema in something like XML Spy, build a Spring context that loads some of the Spring objects needed to make sense of it, and then Spring just passes off the income XML to the beans you create and add to the context. It also provides you with about a dozen ways to receive the XML into your beans from JAXB (1.0 and 2.0), JiBX, JDOM, W3C DOM (ie standard Java DOM) and some other means.