Rest vs Soap

I was reading the difference between REST and SOAP api and figured out why world is moving towards REST apis. I tried to write down few difference between them. I have also given links to few references as well.

http://spf13.com/post/soap-vs-rest

http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Rest(Representational State Transfer )	Soap(Simple Object Access Protocol)
REST describes a set of architectural principles by which data can be transmitted over a standardized interface (such as HTTP)	SOAP defines a standard communication protocol. The Web Services Description Language (WSDL) contains and describes the common set of rules to define the messages, bindings, operations and location of the Web service. WSDL is a sort of formal contract to define the interface that the Web service offers.
The W3C Technical Architecture Group (TAG) developed the REST architectural style in parallel with HTTP 1.1 of 1996-1999.	Microsoft introduced it.
REST is focused on accessing named resources through a single consistent interface	SOAP brings its own protocol and focuses on exposing pieces of application logic (not data) as services
Different data format XML/Json/CSV are supported.	SOAP supports XML
Rest reads can be cached	SOAP read cannot be cached.
While REST supports transactions, it isn’t as comprehensive and isn’t ACID compliant	WS-Security which adds some enterprise security features Need ACID Transactions over a service, you’re going to need SOAP SOAP has successful/retry logic built in and provides end-to-end reliability
Implementation is simpler. Beneficial for public apis. Easier to document and easier for end user/browser as well. You can simply use browser for make a GET request. For other HTTP VERBS such as POST/PUT you can use various browser plugin and fiddler. Advanced rest client chrome extension is my favorite. https://chrome.google.com/webstore/detail/advanced-rest-client/hgmloofddffdnphfgcellkdfbfbjeloo?hl=en-US	SOAP is not as easier to code as compare to REST. Every time I ask my colleague that we need to implement a 3rd party API which is in SOAP he gives me weird look.
The RESTful Web services are completely stateless. Session state is therefore kept entirely on the client. This constraint induces the properties of visibility, reliability, and scalability. Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures. Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn’t have to manage resource usage across requests. Like most architectural choices, the stateless constraint reflects a design trade-off. The disadvantage is that it may decrease network performance by increasing the repetitive data (per-interaction overhead) sent in a series of requests, since that data cannot be left on the server in a shared context. In addition, placing the application state on the client-side reduces the server’s control over consistent application behavior, since the application becomes dependent on the correct implementation of semantics across multiple client versions	SOAP are stateful.
If a user attempts to upload something to a mobile app (say, an image to Instagram) and loses reception, REST allows the process to be retried without major interruption, once the user regains cell service.	If the SOAP service is interrupted it would require more initialization and state code. The client context is stored on the server between requests which make initialization time consuming.