I’ve never been too big on SOAP. It’s nice that there are lots of toolkit implementations out there, but for most of my projects, it just seems like overkill. Many developers joke about the acronym being an oxymoron, because SOAP can quickly lose its simplicity. XML-RPC has its faults, but it’s easier to test and debug, in my experience. But Sam Ruby‘s posting on WS-HTTP has some suggestions that could change that.
Now, Imagine a SOAP 1.3 specification which is identical to SOAP
1.2 with exactly two changes:
- If a
soap:Envelope
is present, then
soap:Header is required.- If you ever want to send a message with zero headers, then you
are required to omit the soap:Envelope and soap:Header
elements.In such a world, people who use SOAP 1.3 enabled toolkits would
be able to construct messages to be sent to eBay. If they are
so inclined, they could write schemas for such messages (in the
schema language of their choice). They could even wrap this
schema in WSDL, and share it amongst themselves.All of a sudden, a class of developers would find eBay to be
“Web Service enabled”. Without requiring any coordination or
changes with eBay.
Sam also cites BlogLines as another use-case. These services both support XML-based APIs that are not based on SOAP or XML-RPC. Currently, you’d have to find or create a toolkit that is written specifically for each of these services. But imagine if these APIs were suddenly available to a large number of existing SOAP client implementations!
Does anybody know what the chances are of such a change being accepted by the XML Protocol Working Group? This kind of stripped-down structure could put the “Simple” back into SOAP.
