On Sat, Dec 15, 2012 at 10:27 AM, Chris Cunnington <
smalltalktelevision at gmail.com> wrote:

>  Why are the tokens in Altitude urls called RESTful?
>

This is an important and subtle topic. Grappling with it is what drove the
development if Altitude, first as a hacked up version of Seaside, and later
as a complete rewrite using Xtreams.

I'm hardly an expert on this, but I try to understand REST from the
original sources. The term is an abbreviation of "representational state
transfer" and refers to an architectural style for distributed applications
that was described in Roy Fieldings doctoral dissertation. [1] You'll note
that "R. Fielding" first is on the list of authors of RFC 2616 [2], which
describes HTTP. With a pedigree like that, it's no surprise that REST is
the most important buzzword of the web development world.

For me, the simplest way to think about REST is to imagine an old-school
static web site: a directory of files being served by a generic Apache
installation, with no fancy plugins, mod_rewrite magic or anything like
that. You have a simple convention where the web page corresponding to a
directory is found in a file called index.html inside that directory, but
otherwise the directory tree in your DOCUMENT_ROOT is mapped directly into
the URL space for that server: http://example.com/foo/ will fetch the
contents of $DOCUMENT_ROOT/foo/index.html, and
http://example/favicon.icowill be found at $DOCUMENT_ROOT/favicon.ico.

There are a couple of important properties of a setup like this:

1. There's a single entry point with a well-known URL: http://example.com/.
The client begins by downloading that page, and from there it discovers
other urls where related resources can be found—css, images, javascript
etc. There might also be hyperlinks to other pages, which the user might
click on to navigate to other pages. The important bit is that all URLs are
provided by the server. At no point does the client generate a url by
following a convention. (ie, something like "the resource I want is of type
Person, and has ID #3, and I want the HTML page that describes that person,
so the url will be /people/3.html"). The urls may in fact follow such a
convention, but that's solely for the convenience of the server, and the
client always receives URLs explicitly, though they might be in relative
rather than absolute form.

2. The client-server transactions are stateless. Each request is
independent, and the server doesn't interpret requests in a client-specific
context. As a consequence, the the URLs that link one document to another
are the same for all clients.

Now, consider Seaside;

1. A Seaside application follows the same pattern, with a well-known entry
point, and all URLs provided by the server.

2. However, a seaside application don't have stateless transactions. Each
url generated by Seaside contains a session identifier and a continuation
identifier, which refer to client-specific context stored on the server.
Thus each client's view of a particular page is unique. Each page is
located at a client-specific URL and has links to other pages at
client-specific URLs. This is why Seaside is not RESTful. (For example,
open up http://www.squeaksource.com/. Now open the same URL in another tab.
The two tabs will have different urls in their location fields. Now
mouse-over the link to the "Projects" page. Each tab will have a different
URL for that link.)

Now, the reason Seaside is such a good framework is that it provides an
abstraction that hides all the details of the way that state is threaded
through the client-server transactions in a web app. It generates urls,
form field names, session ids etc so that application developers don't have
to concern themselves with the details of marshalling and unmarshalling the
state of their application into strings on each request.

Altitude tries to provide that same level of abstraction in a RESTful way.
That is, it behaves like an old-school static web site with respect to
property #2: it produces consistent urls for the "same" resources, and
doesn't store client-specific context on the server.

Andreas Raab criticized Seaside because SqueakSource cannot be indexed by
> Google. The Altitude url tokens look extremely similar to Seaside's.
>
> 1. If they are different, how?
>

Yes. They are superficially similar, in that they are opaque strings
generated by the server. But if you go to http://box3.squeak.org:8624/ and
do the same experiment as I described above with regard to SqueakSource,
you'll see that the URLs are opaque, but consistent. The home page is
always at /, the community page is always at /yqKyLzH7r9ePyzIWOLUBWO9x, for
all clients.


> 2. Can an Altitude application be indexed by Google? If so, which subclass
> of ALUrlStrategy would be employed?
>

Yes. Imagine that Google crawls the new site you've created for Squeak. It
will index /yqKyLzH7r9ePyzIWOLUBWO9x and then when somebody does a search
for "Squeak community" that page will come up (we hope). The user clicks on
the link, and arrives at /yqKyLzH7r9ePyzIWOLUBWO9x, and sees the community
page. Great! If that were a Seaside web site, the user would get a 404
error, because the page that Google saw has expired from the server.

Any strategy could be used, and the site would still be indexable. The
strategies have differences which might make one strategy or another
desirable for different purposes, but RESTfulness isn't a property of the
structure of the URL so much as the way the server handles them. That's why
the locator is named Restful, not the strategies.

Does this make sense?

Colin


[1]  https://www.ics.uci.edu/~fielding/pubs/dissertation/top
[2]  http://tools.ietf.org/html/rfc2616
[3] Well, actually it does, but only for purposes of ranking, not indexing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20121215/acc635a0/attachment.htm