Not whether but when to REST

There is a debate starting to rage about whether REST or SOAP/XML-RPC is better choice for services. Following is my take on REST v/s SOAP/XML-RPC debate, in traditional enterprise computing scenarios.

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.

REST	OO
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.