To understand SOAP and REST you must first understand web services. A web service is a method by which two pieces of software can communicate over a computer network, such as the Internet. SOAP and REST are two different approaches to satisfying this need. They differ in many ways such as their design philosophies, the concepts they define, the effort involved in using them and how they interact with HTTP.
SOAP, Simple Object Transfer Protocol, is built upon the design philosophy of remote procedure calls. In this way SOAP allows software to connect over a network and invoke behavior in other software. This ability solves a common problem in large-scale distributed software systems often found at large enterprises. On the other hand, REST, also known as Representational State Transfer, draws from very different design philosophies. It is based upon the concept of exchanging data. REST web services aim to exchange data as simply as possible by leveraging what is already available.
Since these two techniques differ in philosophy, they also differ in what they define and what they leave up to the implementer. Where SOAP defines a specific format for message exchange using XML, REST does not require any specific format to be used. REST does however constrain the actions performed by a service to those provided by the transfer protocol on which is operates. SOAP allows for any number of methods to be defined thereby providing more flexibility in the behaviors that clients can use.
Implementations of REST and SOAP are also very different. Despite its name, SOAP is a very complicated protocol governed by a set of formal specifications. Implementations often involve large toolkits and are assisted by other protocols like WSDL. Additionally, since behavior is being invoked from a remote system, security is a major concern. Conversely, REST is a general concept that relies mainly on other existing standards to define itself. As a result REST web services can be implemented more easily without the need for REST specific toolkits.
While theoretically a web service can be implemented on top of any data transfer protocol, web services almost always use the ubiquitous HTTP. This is the same protocol your web browser uses to load web pages. REST web service designs attempt to harmonize with HTTP by using its existing vocabulary including both the verbs of HTTP, such as get and post, and the response codes, such as 400 for a user error. This allows REST web services to leverage existing HTTP reliability and scaling technologies quite easily. SOAP, however, is more concerned with consistency regardless of the data transfer protocol used. As a result it draws very little from existing HTTP concepts. SOAP instead defines its own vocabulary, which must be interpreted in addition to HTTP for an integration to function.
In the end SOAP and REST are very different approaches to solving slightly different sets of problems. REST based web services may be easier create and integrate; but some problems, such as system wide distributed transactions, can be more straightforward to implement using behavior centric models like SOAP.
