(It has nothing to due with the fact he has a most excellent first name, but I have another Tim Bray related weblog post.)
Tim Bray has made an entry on a Web interface for Web publishing. I generally agree, and took a couple of quick notes while reading it that I thought I'd share.
Creating an Entry could be improved. I would assume the created date is that in which it was stored in the publishing system so I don't see why you'd need to supply the created. The posted-on date seems more likely. Also, echoing back all of that information with a 201 Created doesn't seem necessary. In all of the examples I have seen by the RESTful elite, 201 Created returns the URI to the newly created resource in the header. That is all you need. I have to agree with them.
Having implemented TrackBack, TrackBack 1.1 does use a simple POST and is somewhat RESTful. (1.0 used GET for all things and was quickly corrected.) It could use some work though. It can also be applied to providing an interface to commenting systems.
Tim's challenge
makes sense, but the one thing I don't get from his post is an acknowledgment of the differences between document and API style interfaces. He seems to favor document style via REST, but in his challenge he mentions also building a version of the API in XML-RPC and/or SOAP. I think this needs some clarification in that you can do something similar in spirit only with XML-RPC and that you have a choice with SOAP. Sam Ruby covered this pretty well already. Relatedly, earlier in the entry, he refers to SOAP being 5 times more complex which I would agree with when it comes to rpc/encoded and all of the luggage that brings, but I wouldn't agree with that statement when it comes to document/literal messaging. That's only 1.25-1.5 times harder.
I believe that any Web publishing interface such as Necho should support REST and SOAP document/literal stylings. SOAP isn't as hard as you would think and it provides the added benefit of non-Web protocols making use of it.
Amongst other issues, XML-RPC does not support document based interfaces. (The specification was recently clarified that string ARE NOT limited to ASCII character set.) It requries some real verbose mashing to come close. This defeats the purpose of a common shared syntax that Necho set out to devise and is why I don't think XML-RPC is relevent or appropriate.
For whatever its worth. Just thinking outloud.
<p>(It has nothing to due with the fact he has a most excellent first name, but I have <a href="http://www.timaoutloud.org/archives/000303.html">another Tim Bray related weblog post.</a>)</p>
<p>Tim Bray has made <a href="http://www.tbray.org/ongoing/When/200x/2003/07/03/HTTP-RSS">an entry on a Web interface for Web publishing</a>. I generally agree, and took a couple of quick notes while reading it that I thought I'd share.</p>
<p>Creating an Entry could be improved. I would assume the created date is that in which it was stored in the publishing system so I don't see why you'd need to supply the created. The posted-on date seems more likely. Also, echoing back all of that information with a <code>201 Created</code> doesn't seem necessary. In all of the examples I have seen by the RESTful elite, <code>201 Created</code> returns the URI to the newly created resource in the header. That is all you need. I have to agree with them.</p>
<p>Having implemented <a href="http://www.timaoutloud.org/archives/000233.html">TrackBack</a>, TrackBack 1.1 does use a simple POST and is somewhat RESTful. (1.0 used GET for all things and was quickly corrected.) <a href="http://www.timaoutloud.org/archives/000206.html">It could use some work though.</a> It can also be applied to providing <a href="http://www.timaoutloud.org/archives/000198.html">an interface to commenting systems</a>.</p>
<p>Tim's <q>challenge</q> makes sense, but the one thing I don't get from his post is an acknowledgment of the differences between document and API style interfaces. He seems to favor document style via REST, but in his challenge he mentions also building a version of the API in XML-RPC and/or SOAP. I think this needs some clarification in that you can do something similar in spirit only with XML-RPC and that you have a choice with SOAP. <a href="http://www.intertwingly.net/stories/2003/01/26/evolve.html">Sam Ruby covered this pretty well already.</a> Relatedly, earlier in the entry, he refers to SOAP being 5 times more complex which I would agree with when it comes to <a href="http://www.fawcette.com/vsm/2002_04/online/online_eprods/webservices_bwagner04_16/default_pf.asp">rpc/encoded</a> and all of the luggage that brings, but I wouldn't agree with that statement when it comes to <a href="http://www.fawcette.com/vsm/2002_04/online/online_eprods/webservices_bwagner04_16/default_pf.asp">document/literal</a> messaging. That's only 1.25-1.5 times harder. </p>
<p>I believe that any Web publishing interface such as Necho should support REST and SOAP document/literal stylings. <a href="http://www.timaoutloud.org/archives/000289.html">SOAP isn't as hard as you would think</a> and it provides the added benefit of non-Web protocols making use of it. </p>
<p><a href="http://www.timaoutloud.org/archives/000284.html">Amongst other issues</a>, XML-RPC does not support document based interfaces. (The specification was recently clarified that string ARE NOT limited to ASCII character set.) It requries some real verbose mashing to come close. This defeats the purpose of a common shared syntax that Necho set out to devise and is why I don't think XML-RPC is relevent or appropriate.</p>
<p>For whatever its worth. Just thinking outloud.</p>
Leave a comment