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

[Mike Schinkel]

Etan Wexler wrote:

>> The structure of URLs is not important knowledge for any API for
applications of REST. In fact, the structure of URLs is totally irrelevant
to any such API.

First off, I  completely disagree with that statement (but I'm always
willing to discuss my beliefs given that new information and good arguments
may change my mind.)

Second, you make an assertion but give no justification.  Can you please
provide justification?  

BTW, since your email someone else emailed contradicting you and he gave
copious references to support his point. I have been studying those
referenced heavily. So if your justification is TBL saying that URLs need be
be opaque, I can provide links to discussions with well formed arguments
that indication TBL's statements did not address the issue in depth, have
been misinterpretted, and are even contradictory to many other statements he
has made.  I can also give arguments to explain why URL design and URL
opacity are not in conflict (which I plan to do in the blog after I make
sure I can do a really clear concise job.)

>> When a program implements an API for an application of REST, the program
relies on the presence of links in content. 
And when the program sifts content to discover links (rather than
constructing URIs according to explanations)...

That is not necessarily true. It can be one valid use-case but is not all
valid use-cases.

>> , the structure of the URL which identifies the link's target is
irrelevant.

The structure of the links are relevent is other use-cases.  Take a look at
the NING REST API (from Marc Andressen's company); it does exactly what I'm
describing (and I can give other examples which I will be doing on the
blog):

http://documentation.ning.com/sections/rest.php

Here's Eventful's EVDB api:

http://api.evdb.com/docs

Here's del.icio.us:

http://del.icio.us/help/api/posts

And there are many more if you need them.

>> Why would the structure of the URLs matter to a program that works
faithfully with an application of REST? 
>> What does the program lack or lose in the following example?

It looses simplicity and ease of implementation as two of many things (the
others which I plan to document on the blog as I have time to flesh them out
completely.)

We should take this conversation off this list.  I don't have a mailing list
set up yet but plan to in the next several days. I will email this list to
notify anyone who wants to participate, and then you and I can pick up this
discussion on a Well Designed Url's mailing list.  So please go ahead and
compose your reply but hold if for the new list...

-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 3:42 AM
To: Microformats REST
Subject: Re: [uf-discuss] "Casual Web Services" and Well Designed
Urls[uf-rest]

Mike Schinkel wrote to Microformats REST:

> After reading your email and those sections of Roy's paper I have 
> absolutely no idea what you were trying to communicate to me.

Let me begin by admitting that I don't know what REST-based Web services
are. Given that you, Mike, were discussing REST-based Web services, I may be
off the mark. I'm discussing REST, with which I presume REST-based Web
services have at least something in common.

The structure of URLs is not important knowledge for any API for
applications of REST. In fact, the structure of URLs is totally irrelevant
to any such API.

> Roy's paper is written in such abstract language that I am unable to 
> see the issues you bring up.  Maybe some examples would help?

The constraint of using hypermedia as the engine of application state can
find alternate expression in the phrase, "Keep it linked, stupid" 
(KILS).

Consider an on-line directory of contact information. The publisher could
specify bits of information and expect consumers to cobble the bits into
URLs for further interaction:

<directory xmlns="data:,the%20Wrong%20Thing">
<contact><name>Jane Doe</name>
<department>Marketing</department>
<employeeID>97P1A</employeeID>
<photo hasPhoto="true"/></contact>
<!--...-->
</directory>

In this scenario, the publisher explains how consumers can and should
construct the URLs <http://example.com/dept/marketing>,
<http://example.com/dept/marketing/staff/97P1A>, and
<http://example.com/dept/marketing/staff/97P1A/photo> given the directory
document.

REST wants links in place of explanations:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> <html lang="en">
<head><title>Corporate directory</title></head> <body><ul><li><a href=
"http://example.com/dept/marketing/staff/97P1A"
 >Jane Doe</a> (see <a href=
"http://example.com/dept/marketing/staff/97P1A/photo"
 >Jane's photo</a>) works in <a href=
"http://example.com/dept/marketing"
 >marketing</a>.</li>
<!--...--></ul></body></html>

The links direct consumers, whether those consumers be humans with a Web
browser or an automated program. When a program implements an API for an
application of REST, the program relies on the presence of links in content.
And when the program sifts content to discover links (rather than
constructing URIs according to explanations), the structure of the URL which
identifies the link's target is irrelevant.

Why would the structure of the URLs matter to a program that works
faithfully with an application of REST? What does the program lack or lose
in the following example?

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> <html lang="en">
<head><title>Corporate directory</title></head> <body><ul><li><a href=
"http://example.com/*z*?foo&"
 >Jane Doe</a> (see <a href=
"http://example.com/...narbley"
 >Jane's photo</a>) works in <a href=
"http://example.com/%0D%25"
 >marketing</a>.</li>
<!--...--></ul></body></html>

-- 


_______________________________________________
microformats-rest mailing list
microformats-rest at microformats.org
http://microformats.org/mailman/listinfo/microformats-rest