I just read this article and I thought it was an interesting way to explain this topic. I found it on the The ServerSide Interoperability Blog's. They have a Mini-Guide for REST and other guides. The REST mini-guide has a long list of resources to help on this topic.
Personally, since I experienced REST services after I started playing with SOAP based web services, I initially considered REST a bad thing. This bad taste in my mouth was due to this customer project, where I was developing a mobile web site (in ASP.NET) and it depended on a REST service that was under the control of another team. They would change the input rules one day, and the output formats the next. It was a pain - but not the fault of REST. Another issue that I had with the situation was that the formats were not documented and that there was no concept of WSDL. I later found someone who had a document, but it was out of date. Due to this, I considered this approach as "a poor man's web services".
Later, I've learned that this is a valid approach for a lot of reasons and a fundamental to Internet communications. Another benefit is that REST is not as bloated as SOAP calls. And, to give more validation, we have several areas of REST support coming.