With SOAP, networked components are modules, meaning they can be seen as "procedures" or "classes" with function calls and parameters. The goal of SOAP is to make a procedure work in remote form, including letting developers find the procedure and properly bind to it for execution. With REST, components represent a resource that you request access to -- a true black box whose implementation details are opaque. There is no presumption with SOAP that the remote components are stateless. The same can be said for a local procedure, where with REST the presumption is that all calls are stateless; nothing can be retained by the RESTful service between executions.
Cloud computing and microservices are almost certain to make RESTful APIs the rule in the future, so it"s important for developers and architects to make the most of REST.
It"s this stateless property that has made REST useful in cloud applications. Stateless components can be freely redeployed if something fails and scaled to accommodate load changes. This is because any request can be directed to any instance of a component; there can be nothing saved in another instance that somehow has to be "remembered" by the next transaction. It"s also possible to develop in SOAP that way, but it"s not required.
REST is preferred for Web use for this reason alone, but the RESTful model is also helpful in cloud services since binding to a service via an API is simply a matter of controlling the way a URL is decoded. If an application "knows" a component or microservice by a URL, changing the IP address associated with that URL will let the request be redirected to a new instance if the original component instance fails. No other directory management is required. If the URL is made to point to a load balancer, then simple algorithms can distribute work because no request can expect to be handled by an instance that "remembers" the state.