My reading on Erlang, and Joe Armstrong's thesis in particular was definitely a factor in getting me into the whole "small REST applications" mindset.
I've also spent a bit of time thinking about the parallels between Erlang's runtime and REST in general. I'm not sure I'd go as far as saying that the microapps stuff I've been doing was directly influenced by Erlang's design, but it definitely helped convince me that it was the right direction to be heading. Nothing's going to be quite as smooth as message passing within an Erlang runtime, but HTTP is similar in that it's independent of the language, allows for network transparency (nodes can be on the same machine or across an oceaon) and the JSON dicts that usually get sent around are looking an awful lot like Erlang tuples. If you think of a URL as something akin to an Erlang Pid, it gets really interesting.
The way that I've been composing microapps involves making requests asynchronously whenever possible and using a message queue app and event notification app. I guess to follow the Erlang model as closely as possible, we would want to avoid using GET. Instead, the client would POST a message onto the queue saying "I'd like you to send this piece of data to this URL", the event notification app would notify the server that there's been a new message added to its queue, which it would retrieve, process, and then POST to the client application's queue a response with the data requested and the client would get an event notification of an item added to its queue and go get it. It's an interesting approach and I've been playing with it for some apps that the latency doesn't matter as much. But for most stuff, synchronous GET requests are so much simpler and easier that it's worth blocking for them.