When to use REST based web services?

REST expose a much simpler interface than SOAP, with some limitations. Development with REST is easier and quicker and this is the reason why most famous web APIs are REST-based.
 
The limitations are related to the protocol: with REST you are bound to HTTP. So it is difficult to handle different transports like MQ or JMS. So if you are designing an application to be used exclusively on the web, REST could be the option. If you are designing a SOA for an Enterprise, that needs to interconnect to multiple systems using multiple transport/channels and having sophisticated transactions to be modeled with BPMs, then it is better to go with SOAP.
Note than you are going to pay SOAP’s flexibility with development complexity: SOAP interfaces are described by the WSDL standard which looks really complicated and is not supposed to be read by humans.

RESTful applications simply rely on the built-in HTTP security (the HTTPS protocol), with SOAP you can have more sophisticated choices, like WS-Security that lets you encrypt only portions of the messages and moves the security handling from the transport layer to the message layer.

REST is younger than SOAP, so it is not as well supported by commercial products (both BPM and ESB products). However new versions of the major ESBs support REST (ex mule, openesb).

RESTful services do not have a strict describtor, they tried to define something simmilar to WSDL, it’s called WADL (https://wadl.dev.java.net/). The WADL is currently not a common standard the adoption is very low and mostly not wanted for RESTful services.

Even for ESB’s most of the vendors where lacking the support some month ago. But now nearly each big ESB vendor (commercial or open source) supports the RESTful protocol. From the usage of an ESB it is currently not a problem to run RESTful services.

If you plan to run a very big deployment with many data interfaces, you will get great benefits using RESTful Services. REST is based 100% on the HTTP rfc (http://www.w3.org/Protocols/rfc2616/rfc2616.html). Many of the RESTful Interface which you see currently on the internet do not fully support HTTP specification, the result is that they could not benefit from it in terms of performance, caching, content negotiation and security. 
One great reason is to use RESTful interfaces is it can easily support different content-types/mime-types. First you think about, vendor specific XML with a xsd definition, later you would like to support AJAX Mashups and even later you think about to support text formats, reports in PDF, and so on. This is very easy to implement with REST because you query always with the same data query but the requested content type is just different.
Another reason why people are using RESTful interfaces is to be scalable like the web (www) and google. This is possible when you are using plain and simple HTTP protocol. You have support from so many standard product like web proxy caches (like SQUID) or other to scale your application a very low effort. For Social Communities you have have now a new Standard for RESTful Service Security. It is called Oauth (http://oauth.net/) which makes authentication over HTTP very easy.

Some other examples where RESTFul Services are dominant:
Amazon AWS: E.g. they offer Services for Storage (S3) and they have SOAP and REST interfaces but over 90% of the clients are using REST
Google Maps is using RESTful uris to provide cachable map tiles
yahoo API’s are mostly build with RESTful interfaces
RESTful Services are very dominant in lighweight web 2.0 API’s for Mashups like OpenSocial
API.

REST design is good for the database driven applications and when client wants quick integration.