From whatever I have read till now, my opinion is that REST is quite close to a distributed object oriented abstraction than a service oriented abstraction. Following table tries to bring out similarities between REST and OO abstraction.
|In REST there are resources||in OO you have Classes and Objects|
|In REST there are HTTP methods(PUT, DELETE, POST, GET ) for lifecycle management||in OO you have facilities provided by OO language (Constructor, Destructor, method invocation, accessor methods)|
|In REST resources keep application state information||in OO object represents the state|
|In REST type safety is provided by XML schema||in OO type safety is provided by pre-shared class definitions (e.g. using .h files or java .class files)|
|In REST dynamic invocation is possible because of repository||in OO dynamic invocation is possible because of reflection.|
Of-course REST provides a more open distributed object oriented mechanism than say CORBA or EJB. It does it by usage of XML schema for marshalling/unmarshalling and open protocol like http (as against dcom, iiop or rmi).
But it is bound to face the some of the problems that distributed object oriented mechanisms faced. e.g. granularity of objects, scalability related issues, differing consumer experience based on lazy or early instantiation of resource graphs (object graphs in OO).
REST is an interesting way of implementing distributed object oriented mechanism, and there are times this abstraction is better suited than pure service oriented abstraction. So in my opinion debate should not be either REST or SOAP/XML-RPC, but when to use REST and when to use SOAP/XML-RPC. The limiting factor for time being is availability of tooling and skills. Over period of time these will develop and then, within enterprises both can co-exist.