In another thread to my O'Reilly post on Weblogs, Web services and the future, an anonymous poster raises the notion of using SOAP instead of XML-RPC stating SOAP is a great service, supported by all the big players.
Quite a valid thought. Another anonymous poster chimes in SOAP is a useless waste of time and a wonderful example of NeedlessComplexity. Use HTTP. What else needs to be done besides GETting data, POSTing new data, PUTing changed data and DELETEing dead data? Focus on clean resource-space identifiers [URIs] and meaningful XML blocks. Then, DO NOT wrap them in an XML-RPC or SOAP noise. Just use the data.
I understand where this anonymous poster is coming from. As I have said repeatedly RSS is the Web service we already have. I also admit to having RESTful leanings however they are not absolute.
I asserted that creating a SOAP/RSS hybrid would simpler then most people think when document literal encoding is applied. Most developers are familar with the RPC encoding which does have more overhead and issues particularly in this case. Encoding document-based content into RPC forms is part of the reason why the XML-RPC based solutions struggle. Sam demonstrates the notion of SOAP interface with RSS at the end of his essay. Here is some additional reading on the matter here here and here. In comparision SOAP/RSS is not that much more complex then just RSS over HTTP (the pure
REST way).
SOAP does have its place. For example, wouldn't it be helpful to post to your weblog via an email message in a standard way? (This assumes the client is handling the SOAP encoding of course.) I think, yes.
<p>In another thread to my O'Reilly post on <a href="http://www.oreillynet.com/cs/weblog/view/wlg/3229">Weblogs, Web services and the future</a>, an anonymous poster raises the notion of using SOAP instead of XML-RPC <a href="http://www.oreillynet.com/cs/weblog/view/cs_msg/19188">stating</a> <q>SOAP is a great service, supported by all the big players.</q> Quite a valid thought. Another anonymous poster <a href="http://www.oreillynet.com/cs/weblog/view/cs_msg/19221">chimes in</a> <q>SOAP is a useless waste of time and a wonderful example of NeedlessComplexity. Use HTTP. What else needs to be done besides GETting data, POSTing new data, PUTing changed data and DELETEing dead data? Focus on clean resource-space identifiers [URIs] and meaningful XML blocks. Then, DO NOT wrap them in an XML-RPC or SOAP noise. Just use the data.</q></p>
<p>I understand where this anonymous poster is coming from. As I have said repeatedly <a href="http://www.oreillynet.com/pub/wlg/2653">RSS is the Web service we already have</a>. I also admit to having RESTful leanings however they are not absolute.</p>
<p><a href="http://www.oreillynet.com/cs/weblog/view/cs_msg/19188">I asserted</a> that creating a SOAP/RSS hybrid would simpler then most people think when document literal encoding is applied. Most developers are familar with the RPC encoding which does have more overhead and issues particularly in this case. Encoding document-based content into RPC forms is part of the reason why the XML-RPC based solutions struggle. Sam <a href="http://www.intertwingly.net/stories/2003/01/26/evolve.html#SOAP">demonstrates the notion of SOAP interface with RSS</a> at the end of his essay. Here is some additional reading on the matter <a href="http://www.intertwingly.net/blog/1112.html">here</a> <a href="http://www.intertwingly.net/blog/1010.html">here</a> and <a href="http://www.snellspace.com/blog/archives/000127.html">here</a>. In comparision SOAP/RSS is not that much more complex then just RSS over HTTP (the <q>pure</q> REST way). </p>
<p>SOAP does have its place. For example, wouldn't it be helpful to post to your weblog via an email message in a standard way? (This assumes the client is handling the SOAP encoding of course.) I think, yes.</p>
Leave a comment