On 2012-12-15 1:28 PM, Colin Putney wrote:
>
>
>
> On Sat, Dec 15, 2012 at 10:27 AM, Chris Cunnington 
> <smalltalktelevision at gmail.com <mailto: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.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?
>
Yup. I just pulled out my copy of RESTful Web Services (O'Reilly, 2007) 
and reviewed the stuff I highlighted four years ago. I get it. I 
understand why you serialize and hash things. I see Etags in the bigger 
picture. To review this stuff is to be pulled back into a large topic. 
It would seem that Altitude is an extremely RESTful framework. That 
opens a door for Smalltalk to participate in a larger world.

Chris

> Colin
>
>
> [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/top 
> <https://www.ics.uci.edu/%7Efielding/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/9c6a9982/attachment.htm