four Altitude questions

ALSequentialUrlStrategy generates urls in a predicable sequence: /1, /2, /3 etc. This is handy for testing. It might also be good for something like a URL shortening service where the shortest possible URLs are desirable. 

ALRandomUrlStrategy does the opposite. It generates pseudo-random unguessable URLs. That makes a web application more secure

ALDigestUrlStrategy provides a middle path between predictability and unpredictability. It creates urls that are difficult to guess, but consistent. So, for example, two different images running the same application would generate the same urls for equivalent resources. (This wouldn't be the case with random urls).

On Sat, Dec 15, 2012 at 10:27 AM, Chris Cunnington <[hidden email]> 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.ico will 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.