>> The constraint of hypermedia as the engine (not merely an engine) of application state means that using anything other than hypermedia to progress from interaction to interaction is not within REST. Explanations in natural languages are not hypermedia.
So are you saying that a REST API can only have one entry point URL and all others must be discovered? (And if so, where did you get this perception that this would be a requirement?) >> I fail to find a contradiction of my position. Serendipitous use is something in which human beings engage; it is not something in which computer programs engage. Programmers are human beings. So rather than call a URL that will tell it what the "add" URL is which they then get to indirectly, they will just call the "add" url because it has ideally been well designed and is in a human readable, understandable, and memorable format. -Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Etan Wexler Sent: Saturday, October 21, 2006 5:55 AM To: Microformats REST Subject: Re: [uf-rest] "Casual Web Services" and Well Designed Urls Nick Gall wrote to Microformats REST: > Nothing in REST, nothing in WWW architecture, and certainly nothing in > Roy T Fielding's dissertation forbids constructing URIs based on "out > of band documentation". I was discussing REST, which Roy Fielding defined in his dissertation. I was not discussing Web architecture as defined in any other document, not even other documents by Roy Fielding. In particular, I was discussing a computer program's construction of URIs, as opposed to a human's construction of URIs. (If my writing was unclear, I apologize.) I stand by what I wrote. The constraint of hypermedia as the engine (not merely an engine) of application state means that using anything other than hypermedia to progress from interaction to interaction is not within REST. Explanations in natural languages are not hypermedia. I admit that Roy Fielding's dissertation (<http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>) does not declare that REST forbids out-of-band explanations as an engine of application state. The dissertation leaves many points implicit, and, rather than expressing conformance criteria after the mode of RFC 2119, simply defines what REST is. Whatever does not fall within the definition is implicitly forbidden. > Here's what [Roy Fielding] has to say on the matter [...]: > > "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." > <http://rest.blueoxen.net/cgi-bin/wiki.pl?RestAndUriOpacity#nid1SK> I fail to find a contradiction of my position. Serendipitous use is something in which human beings engage; it is not something in which computer programs engage. As a human being, I frequently practice serendipitous use. For example, I used my knowledge of Wikipedia to construct the URI "http://en.wikipedia.org/wiki/Representational_State_Transfer";. I accessed the resource which the URI identifies. In the representation returned, there is a link to <http://upload.wikimedia.org/wikipedia/en/thumb/8/89/Resttriangle.svg/273px- Resttriangle.svg.png>. I went on a hunch, constructed the URI "http://upload.wikimedia.org/wikipedia/en/thumb/8/89/Resttriangle.svg/600px- Resttriangle.svg.png", and accessed the resource which the latter URI identifies. As a human being, I am not bound by the rules of the application. > And here is what the W3C TAG currently has to say about it: > http://www.w3.org/2001/tag/doc/metaDataInURI-31. The distinction which I drew between computer programs and humans is a distinction which the cited document draws. > 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. Well, RFC 3986 provides documentation for all URIs. > don't speculate from the text embedded in the URI what the rules are > for composing such a URI. Such speculation is serendipitous use that Roy Fielding encourages (albeit not in his dissertation) and that the authors of the draft TAG finding acknowledge as "important to Web users". -- _______________________________________________ microformats-rest mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-rest _______________________________________________ microformats-rest mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-rest
