<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2012-12-15 1:28 PM, Colin Putney
wrote:<br>
</div>
<blockquote
cite="mid:CAD+=c1iwj2YvRsApectAZX0v=Pi1w55sGFSPwQ6qVLVTc99UQQ@mail.gmail.com"
type="cite"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sat, Dec 15, 2012 at 10:27 AM, Chris
Cunnington <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:smalltalktelevision@gmail.com"
target="_blank">smalltalktelevision@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Why are the tokens in Altitude urls called RESTful?</div>
</div>
</blockquote>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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: <a moz-do-not-send="true"
href="http://example.com/foo/" target="_blank">http://example.com/foo/</a>
will fetch the contents of $DOCUMENT_ROOT/foo/index.html,
and <a moz-do-not-send="true"
href="http://example/favicon.ico" target="_blank">http://example/favicon.ico</a>
will be found at $DOCUMENT_ROOT/favicon.ico.</div>
<div><br>
</div>
<div>There are a couple of important properties of a setup
like this:</div>
<div><br>
</div>
<div>1. There's a single entry point with a well-known URL: <a
moz-do-not-send="true" href="http://example.com/"
target="_blank">http://example.com/</a>. 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.</div>
<div><br>
</div>
<div>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. </div>
<div> </div>
<div>Now, consider Seaside;</div>
<div><br>
</div>
<div>1. A Seaside application follows the same pattern, with a
well-known entry point, and all URLs provided by the
server. </div>
<div><br>
</div>
<div>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 <a moz-do-not-send="true"
href="http://www.squeaksource.com/" target="_blank">http://www.squeaksource.com/</a>.
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.)</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Andreas Raab
criticized Seaside because SqueakSource cannot be indexed
by Google. The Altitude url tokens look extremely similar
to Seaside's. <br>
<br>
1. If they are different, how? <br>
</div>
</blockquote>
<div><br>
</div>
<div>Yes. They are superficially similar, in that they are
opaque strings generated by the server. But if you go to <a
moz-do-not-send="true" href="http://box3.squeak.org:8624/">http://box3.squeak.org:8624/</a>
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.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">2. Can an Altitude
application be indexed by Google? If so, which subclass of
ALUrlStrategy would be employed? <br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Does this make sense?</div>
<div><br>
</div>
</div>
</div>
</blockquote>
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. <br>
<br>
Chris<br>
<br>
<blockquote
cite="mid:CAD+=c1iwj2YvRsApectAZX0v=Pi1w55sGFSPwQ6qVLVTc99UQQ@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Colin</div>
<div><br>
</div>
<div><br>
</div>
<div>[1] <a moz-do-not-send="true"
href="https://www.ics.uci.edu/%7Efielding/pubs/dissertation/top"
target="_blank">https://www.ics.uci.edu/~fielding/pubs/dissertation/top</a></div>
<div>[2] <a moz-do-not-send="true"
href="http://tools.ietf.org/html/rfc2616" target="_blank">http://tools.ietf.org/html/rfc2616</a></div>
<div>[3] Well, actually it does, but only for purposes of
ranking, not indexing. </div>
<div><br>
</div>
<div>
<br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
<br>
<br>
</body>
</html>