I’ve tried to ignore tech fashions, but the REST buzzword keeps popping up everywhere. From what little I’ve been able to understand, the REST architectural concept is a generalization of the web. All objects are restricted to a simple API: GET, PUT, POST and DELETE methods. Since you can’t get more methods, you are forced to define lots of objects (they call them “resources”). The messages passed to and from objects could be anything: text, XML, JSON, etc. They are application specific. The main benefit of REST is that it builds on top of the Web. Since the Web scales well, then your application can scale well by reusing those same techniques and technologies.
I don’t think Web Services (WS-*) contradict REST architecture, but it does require a splash of self-discipline to keep your service fairly stateless. In fact, WS-* subsumes REST. If I write a service that only has those 4 methods, isn’t that a REST architecture? That REST prefers URLs to SOAP messages is an insignificant implementation detail. The only reason I can see to prefer REST is that it doesn’t require the libraries required to process the WS-* standards. Is that all?