Mark and Clark over at developersmackdown.com just published ‘my’ show: http://developersmackdown.com/archives/SingleShow/30. We spent time talking about REST and SOAP as well as a number of other topics related to REST. One of the things that I don’t think was made clear enough was that REST and SOAP are not competing service techniques. Each technology/interface type has an appropriate use case. When integrating applications within an enterprise, the development team needs to worry about:
– Security
– Transactions
– Reliable delivery of messages
– Integration with tooling for other developers
In the enterprise case, WCF + SOAP/WS-* can make integration between systems pretty simple. Yes, the teams may struggle with getting the security setup just right between domains, but overall, things will go well, especially if the setup requires communicating between different WS-* implementations. Finally, enterprise integrations typically happen for applications running on the same network/VPN. The infrastructure for an enterprise is different than that for the web. It’s important to build your applications for their environment.
When integrating applications over the Internet, sometimes WS-* adds too much complexity. For extensive integration across partners who are connected via the Internet, there is some benefit to understanding REST. REST will allow your application to scale using the HTTP architecture. Features such as caching, proxy servers, and the general uniform interface exposed by HTTP helps make things work better on the global network.
Because of my point of view here, when asked “do you prefer SOAP or REST?”, I am forced to answer “For what scenario?” I’m not popular in either circle, but understanding both helps me get stuff done.
Karmic Code Monkey 