Difference between REST and SOAP

The two implementations of Web services architecture are actually completely different; they may accomplish much the same results, but they go about their jobs in entirely separate ways.
With SOAP, each Web service has its own URL, and a request made of that URL is submitted as a message in an XML enclosure. Each request uses an instruction that's part of the namespace of the service, which is itself explained through an XML scheme called Web Services Description Language (WSDL). So a Web client passes a message to the service, using the lexicon outlined by WSDL and enclosed in a SOAP envelope. The service then responds with results that are enclosed in a very symmetrical fashion, so that the queried element and the response tend to match up.
The key benefits of SOAP are that it is transport-agnostic (just because it uses HTTP now doesn't mean it has to in ten or fifteen years' time), and that it's easy to associate a Web service with an appropriate URL. That makes directories of Web services easier to assemble.
REST is actually a bit simpler to explain, especially to someone who hasn't grown too accustomed to SOAP. Unlike SOAP, REST relies entirely on HTTP. But because of that, its request language is already known; there are only four "verbs" in REST which translate directly to the GET, POST, PUT, and DELETE. So the need for WSDL on the request side is completely thwarted.
With REST, the item of data the client requests -- not the Web service itself -- is the target of the URL. For example, the field where a customer's surname would appear in a database may be the URL, whereas in SOAP, the URL refers to the service to which a request for that surname would be placed in an envelope. The server responds with a message in an XML envelope that pairs both the item that was requested and its response, which makes it easier for an auditing application to account for data transactions.
Is REST necessarily an easier way to go? It is if you're developing applications using a new concept called the model view controller scheme. These are the "composite" applications to which Microsoft's marketing literature refers; they involve three separate components which may be programmed in completely different languages, and may be running on separate processors. The model component sets up the data that's the subject of an application, whereas the view component prepares a meaningful relationship of that data for a human reader. This tends to translate well to systems where JavaScript or dynamic language code can do the modeling, and HTML can set up the view. The controller may be a server application that maintains the active state and integrity of the database.
It's an extremely sensible way to think of a network application, and it may be much easier to develop such a system because the three aspects of maintaining it can be delegated to separate development teams. But it almost mandates that the "what" of the application -- the part which the model component is setting up, and the view is preparing to lay out -- have a discrete name, without relying upon some Web service to give it a name later on during the transaction process. That's where the REST model may be a better fit.