[uf-rest] "Casual Web Services" and Well Designed Urls

[Mike Schinkel]

>> 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: microformats-rest-bounces at microformats.org
[mailto:microformats-rest-bounces at microformats.org] 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
microformats-rest at microformats.org
http://microformats.org/mailman/listinfo/microformats-rest