Colin,

thank you for the detailed explanations. Well written, and they make a
lot of sense!

Taking the example of the new Squeak website

   http://box3.squeak.org:8624/yqKyLzH7r9ePyzIWOLUBWO9x

points to the Squeak community web page (mailing lists etc.).

It  is exciting to see this RESTful behavior in action. This opens up
a lot of new options.

Chris, BTW the blue bar appears double in IE9 whereas in FF17 it is fine.

I did not realize that the new Squeak website has this behavior as the
URL looked very Seaside-like. So I did not even try to look at the url

   http://box3.squeak.org:8624/yqKyLzH7r9ePyzIWOLUBWO9x

in different browsers.

The immediate question which now comes up is

how can we have something like

   http://box3.squeak.org:8624/community

i.e.

     yqKyLzH7r9ePyzIWOLUBWO9x

replaced by

     community

?

--Hannes

On 12/15/12, Colin Putney <colin at wiresong.com> wrote:
> 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.
>