REST afarian and SOAP farian Religions

I have recently viewed an enlightening presentation from de ESRI 2009 Developer Summit Conference about REST and or versus SOAP. In the past I have been working for the ORCHESTRA project, an EU FP6 project with the objective of "designing and implementing the specifications for a service oriented spatial data infrastructure for improved interoperability among risk management authorities in Europe, which will enable the handling of more effective disaster risk reduction strategies and emergency management operations". The technical underpinnings supporting it was indeed SOAP services, and one of its achievements has been to extend and create new OGC-like services supporting SOAP. Once this new services was created they were used in diferent pilots to solve different situations, such as fire risks or coastal pollutant risks. To do that, in almost every pilot, several ORCHESTRA services were combined using SOAP calls. Obviously, there was a great effort in designing the contract and interfaces for these services, and once this was achieved the interaction allowed to merge, geographical information with geoprocessing analysis, without the need for a common software platform or infrastructure.
Nevetheless, from a developer point of view, create such application using SOAP was a real challenge. The lack of good tools (at least from Java) to work comfortably with SOAP services makes it really harder. I have to say that, to this end, I found Netbeans IDE much more easy to use and integrated than Eclipse. The real problem was that pilots, were web applications, and using SOAP with web applications is difficult. From Javascript it is possible to create SOAP calls (see example) but you have to deal manually with really complex XML parsing, and we know that this is a little bit trickier from JavaScript. The solution to this was, in most cases, to encapsulate this type of calls, inside server side logic and use AJAX to retrieve the required information back to the web application. The point here was, that sometimes, we were just sending to the server a pair of coordinates (X, Y) to get the result of some type of geoprocessing. And, once I saw the video mentioned before, I realized that this was the kind of situations were a REST service would have make much more sense. Not only that, to create a complete SOAP call to the server to send just X and Y coordinates, instead of using JSON, it was not the best solution, at least if you are developing a web applications.
For this reason, sometimes a REST aproach is more appropiated.