Is Resource view (REST) as powerful as Object view?

We are comfortable with object view of the world. Everything is a class and each class has data members and method members and has relationships to other classes. In plain English we have nouns and verbs. If you are user of a object API, you get the right noun instance and call the verb on it - get the duck instance and say "fly". We can model bank domain to rocket domain using this.
Modeling this as a service as in SOA or method call as in RPC is also straightforward. Calling a method on a remote object is possible (CORBA). And that in turn is equivalent to a method call which has object identity as an argument.
Is Resource view equally powerful? I thought a service "SendEmail" might be tough to be seen as a Resource that has a universal interface (HTTP method). http://www.prescod.net/rest/restmail/ shows that this is possible. Does it look contrived?
Well, we could analyze this with two approaches. By making the whole world look like resources we are converting a set of "nouns and verbs" to fixed few verbs and lots of nouns. I as a human can do many things - run, sleep, think etc. How do i reduce it to nouns? One way is state model approach - i see things as states and each state is addressable by URI. So i have a running man, sleeping man etc. Is a state a resource? Not really.
Another way to look is that we are only interested in representation and transfer of representations between client and server. So you get representation of a resource - which is a man. And you update the resource's representation on client, say you change it from running to sleeping and then you call update onto the resource again. It is like you take a toy look at it and turn the switch on and put it back - the toy starts playing. So any object model can have an equivalent resource model where object are resources, data members are part of representation of object and method calls are triggered on server side by client modifying the representation of object and updating the server. This has an integral part, serialization of object into an representation that can be shipped to far away place and a change could be applied with a returning representation.
On a broader view REST looks like shopping experience. You go to a shopping mall and all shops are resources. You hop from one to another - your state transfers, resource stays where they are and you only get a representation of resource (godown is the actual resource).
It also looks as if REST is remote object protocol - except that methods are not called directly. They however could be effected by state change. How does document style services differ - well, they look more closer to REST than RPC style services. The equivalence is when there are seven kind of services - Get, Post, Head, Put, Delete, Trace and Option.
This again takes me to LISP and turing machine. Anything can be modeled by a simple list or a set of read/write/mark instructions. My faith in higher level ideas like REST is strengthened.

REST is primarily for remote communication. One will not implement their business logic entirey using just resources - it will be object model. REST representations are photographs of these object model - one object at a time.