SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) provide mechanisms for requesting information from endpoints (SOAP) or from resources (REST). Perhaps the best way to think of these technologies is as a method of making a remote procedure calls against a well-defined API. SOAP has a more formal definition mechanism called WSDL (Web Services Definition Language) and is a bit more complex to implement. REST uses the standard HTTP request and response mechanism, simplifying implementation and providing for a looser coupling of the client and server. Note that REST also supports the transfer of non-XML messages such as JSON (JavaScript Object Notation
Which is better, REST or SOAP?
This is one of the most common questions I get about REST, and it is probably the least fair. Both REST and SOAP are often termed "Web services," and one is often used in place of the other, but they are totally different approaches. REST is an architectural style for building client-server applications. SOAP is a protocol specification for exchanging data between two endpoints.
Comparing REST with the remote procedure call (RPC) style of building client-server applications would be more accurate. RPC is a style (rather than a protocol, which is what SOAP is) of building client-server applications in which a proxy (generally generated from metadata) is used in the client's address space to communicate with the server and the proxy's interface mimics the server's interface. Although SOAP doesn't require the RPC style, most modern SOAP toolkits are geared toward (at least they default to) using RPC.
In contrast to RPC, REST lacks the metadata-generated proxy (see the next question for more information), which means that the client is less coupled to the service. Also, because REST relies on the semantics of HTTP, requests for data (GET requests) can be cached. RPC systems generally have no such infrastructure (and even when performing RPC using SOAP over HTTP, SOAP responses can't be cached because SOAP uses the HTTP POST verb, which is considered unsafe). SOAP intentionally eschews HTTP, specifically to allow SOAP to work over other protocols, so it's actually a little disingenuous to call SOAP-based services Web services.
My perspective is that both REST and SOAP can be used to implement similar functionality, but in general SOAP should be used when a particular feature of SOAP is needed, and the advantages of REST make it generally the best option otherwise.
ref:
Soap vs Rest discussions - http://blogs.msdn.com/b/zainnab/archive/2007/12/16/rest-vs-soap-decision-decisions-decisions.aspx
Introduction to Restful Webservices - http://msdn.microsoft.com/en-us/magazine/dd315413.aspx
Web Services, Part 1: SOAP vs. REST - http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
Stefan Tilkov: REST vs SOAP - http://www.innoq.com/blog/st/2006/06/30/rest_vs_soap_oh_no_not_again.html
Roots of REST vs SOAP - http://www.prescod.net/rest/rest_vs_soap_overview/
REST vs SOAP from StackOverflow -http://stackoverflow.com/questions/209905/rest-and-soap
Giving SOAP a REST -http://www.devx.com/DevX/Article/8155
