We feel that [SOAP is] overly complicated. It's been taken over by the enterprise people, and when that happens, usually nothing good comes of it.
Representational State Transfer, REST vs SOAP: yet another software religious war, in which truth was an early casualty. For me, the following puts these technologies in their place.
''To be fair, REST isn't the best solution for every Web service. Data that needs to be secure should not be sent as parameters in URIs. And large amounts of data, like that in detailed purchase orders, can quickly become cumbersome or even out of bounds within a URI. In these cases, SOAP is indeed a solid solution. But it's important to try REST first and resort to SOAP only when necessary. This helps keep application development simple and accessible.
Developers need to understand that sending and receiving a SOAP message isn't always the best way for applications to communicate. Sometimes a simple REST interface and a plain text response does the trick--and saves time and resources in the process.''
While the major vendors and standards bodies continue to build the core Web services stack around SOAP, a small and sometimes vocal minority eschews SOAP in favor of Web services based on Representational State Transfer (REST). While there is some truth in proponents' claims that REST is simpler and faster, they tend to ignore issues of quality of service (QoS), which are the primary driver of the growing complexity of the SOAP-based Web services stack. Oddly enough, today's REST versus SOAP debate sounds almost the same as the SOAP versus CORBA debates from four years ago. REST has a place as a transition step to Web services, and it may even garner a long-term place for simple create-read-update-delete types of interactions, but tooling and infrastructure for SOAP provide greater productivity, making it a more strategic investment for a wider range of long-term requirements.
Dave: The Cool Function in XMLSpy is AWESOME - but not worth the US$1,000.00 price tag. Surely there is something that can be done to do the same thing in Native Tcl...
LV I would guess that while something could be written in native Tcl to help test and debug soap, it is doubtful that it already exists and is available for free. If it exists, it probably is either internal to someone's company, or is on the slate for someone to develop and sell. However don't let that discourage you from writing such a thing!
[PT] write: This article covers version 1.3 so is a little old. It's still a good introduction but you'll want to check the examples that are part of the TclSOAP distribution. Especially if you intend to send structures or advanced types over SOAP.