<pre style="font-family: arial,sans-serif;"><font size="2"><b>Etan Wexler</b> wrote to Microformats Discuss:<br>&gt;REST does not permit programmatic construction of URIs in which the<br>&gt;construction uses of out-of-band knowledge and bits of data.
</font></pre><font style="font-family: arial,sans-serif;" size="2">I'm sorry, but this is flat out wrong. Nothing in REST, nothing in WWW architecture, and certainly nothing in Roy T Fielding's dissertation forbids constructing URIs based on &quot;out of band documentation&quot;. This is one of the most pernicious misunderstandings of web architecture that I feel compelled to help stamp it out.
<br><br>Here's what RTF has to say on the matter (see <a href="http://rest.blueoxen.net/cgi-bin/wiki.pl?RestAndUriOpacity#nid1SK">http://rest.blueoxen.net/cgi-bin/wiki.pl?RestAndUriOpacity#nid1SK</a>):<br><br></font>&quot;REST does not require that a URI be opaque. The only place where
the word opaque occurs in my dissertation is where I complain about the
opaqueness of cookies. In fact, RESTful applications are, at all times,
encouraged to use human-meaningful, hierarchical identifiers in order
to maximize the serendipitous use of the information beyond what is
anticipated by the original application.&quot; &nbsp;&nbsp; <a class="nid" title="1SK" href="http://rest.blueoxen.net/cgi-bin/wiki.pl?RestAndUriOpacity#nid1SK">(1SK)</a>
<div class="indent">
<p><a name="nid1SL" id="nid1SL"></a>-- <a href="http://groups.yahoo.com/group/rest-discuss/message/3232" class="extlink">http://groups.yahoo.com/group/rest-discuss/message/3232</a> &nbsp;&nbsp; <a class="nid" title="1SL" href="http://rest.blueoxen.net/cgi-bin/wiki.pl?RestAndUriOpacity#nid1SL">
(1SL)</a></p>
</div>And here is what the W3C TAG currently has to say about it: <a href="http://www.w3.org/2001/tag/doc/metaDataInURI-31">http://www.w3.org/2001/tag/doc/metaDataInURI-31</a>.<br><br>In short, the only time a URI should be considered opaque is when the person looking at it has no documentation or code (eg a FORM element) to support their speculation of what the components of the URI might mean. To put it simply: URI's mean only what authorized code or documentation says what they mean (and how they can be composed); don't speculate from the text embedded in the URI what the rules are for composing such a URI.
<br><br>-- Nick<br clear="all"><font style="font-family: arial,sans-serif;" size="2"><br></font>-- <br>Nick Gall<br>Phone: +1.781.608.5871<br>AOL IM: Nicholas Gall<br>Yahoo IM: nick_gall_1117<br>MSN IM: (same as email)<br>
Google Talk: (same as email)<br>Email: nick.gall AT-SIGN gmail DOT com<br>Weblog: <a href="http://ironick.typepad.com/ironick/">http://ironick.typepad.com/ironick/</a><br>Furl: <a href="http://www.furl.net/members/ngall">
http://www.furl.net/members/ngall</a>