Have been using the ReST philosophy (or pattern?) for almost 15 years without any issues. ReST itself does not define the use of a specific technology and is not a standard by itself, it is pretty abstract. Using the URI and HTTP standards are just a way to apply it. Other technologies can be used as well, like SMTP / MIME or something developed yourself as soon as the ReST constraints can be applied. Adding the ReST constraints is what brings the advantages. It is really flexible and allows for easy composition of "layers" through "connectors". A caching proxy is an example of a "connector". If ReST could be compared to something in programming it is very similar to "monads" as used in functional programming.
Recursion can be done by the use of nested "resource identifiers" (SSI or ESI for example) inside the returned "representation". A "connector" may then decide to do another request to replace the "identifier". If the "connector" uses caching it may not even need to do another sub-request. I use this to do something like what Facebook's Relay does. As the full state is always being sent along with every request it is very easy to scale because the servers, wherever they are, always have enough context to be able to work with it. A server may even ignore what it does not understand for the next layer to handle it called "partial understanding" which is supported by XML for example. Unfortunately when using JSON most of these advantages are lost. That is why I prefer a less verbose "XML Infoset" similar to JSON while still keeping all the advantages.
Recursion can be done by the use of nested "resource identifiers" (SSI or ESI for example) inside the returned "representation". A "connector" may then decide to do another request to replace the "identifier". If the "connector" uses caching it may not even need to do another sub-request. I use this to do something like what Facebook's Relay does. As the full state is always being sent along with every request it is very easy to scale because the servers, wherever they are, always have enough context to be able to work with it. A server may even ignore what it does not understand for the next layer to handle it called "partial understanding" which is supported by XML for example. Unfortunately when using JSON most of these advantages are lost. That is why I prefer a less verbose "XML Infoset" similar to JSON while still keeping all the advantages.