Web services seem to be multiplying like rabbits these days. For a good sampling of just how many there are check out the Programmable Web API list. In general it is pretty easy to consume basic REST web services but after you have done it enough it starts getting old. Thankfully for those of us who like to tinker with a lot of the new APIs there is HTTParty to make it quick and easy.
I generally don't recomend using SOAP instead of REST but I have been required to use SOAP so much now that I think it is inevitably going to be a requirement for a long time for certain projects. So when I noticed a question on stack overflow about using SOAP on the Google App Engine I thought it might be a nice exercise to see how easy it is to get fringe toolsets to work in the GAE.
While working on an SOAP service I needed to create a number of clients for different languages. This would normally not be that big of a challenge except that the SOAP service had custom headers for doing authentication. Because of the complexity in setting up Axis to use WS-Security the choice was made to do authentication by adding a few out of band SOAP header values. The first few implementations went fine but then I came to C# and had a problem.
I wrote about SOAP vs REST a few weeks ago. Today I noticed this article with a presentation about putting together Rails REST services with ActiveResource.
Recently it seems like the SOAP vs REST debate is heating up. Most of the debate seems to be leaning toward convincing people to not use SOAP based on its increasing complexity. Different people have different views on what REST is but in general if you look at the SOAP specifications or SOAP Standards and Web services and then look at the REST specification, REST for the Rest of Us, or REST you see that in general there is a lot more complexity to SOAP and that is just SOAP itself and not any of its extensions. Here are some good articles I've found that should give you insight into the debate:
- REST vs HTTP+POX vs SOAP – A simple explanation of REST and SOAP.
- How I Explained REST to My Wife – Another simple explication of what REST is.
- The S Stands for Simple – A conversation that expresses the issues with using SOAP.
- REST for Web Services – The outline for a new REST for web services book.
- The REST Dialogues – A set of fictional dialogs on REST vs SOAP.
- The REST Dialogues, A Real eBay Architect – A response to "The REST Dialogues" by a real eBay architect.
- 85% of Amazon calls are to REST version of their API
- Google turns off SOAP API
- Why SOAP sucks
After looking over the above references you may be interested in looking at Programmable Web's API list and see what others are using. The majority of the public services listed offer REST interfaces with some offering both REST and SOAP and very few offer just SOAP. Even though REST seems to be in favor now I believe there are still plenty of areas where SOAP makes sense when you have resources to devote to feeding and caring for it.