[PRL] RE: REST (fwd)

[David A. Herman]

Here's Anton's first response to my prodding.

Dave

---------- Forwarded message ----------
Date: Wed, 16 Feb 2005 03:14:56 -0500
From: Anton van Straaten <anton at appsolutions.com>
To: Dave Herman <dherman at ccs.neu.edu>
Subject: RE: REST

Hi Dave,

Thanks for the prod. ;)  The urge is there, the time hasn't been.  It will
happen though, I've just been working through a list of priorities.

I have some collected material here on a wiki at home, which I'll put up
somewhere that you can reach it and send you a URL.  In the meantime, a
minor brain+link dump follows.

> Incidentally, can you point me to a good tutorial on REST?
> Most of what I've seen so far is really fuzzy.

The definitions *are* fuzzy.  Adding to the fuzziness is the fact that there
are really two different notions of REST - one is the one Fielding
explicitly claims to have provided, which is a descriptive explanation of
the architectural features of the web:

  "REST is an architectural style that models system behavior for
network-based applications. When an application on the Web is implemented
according to that style, it inherits the interconnectivity characteristics
already present in the Web. REST's purpose is to describe the
characteristics of the Web such that they can be used to maximum
advantage -- it does not need to define them. REST isn't supposed to be a
baseball bat; it is supposed to be a guide to understanding the design
trade-offs, why they were made, and what properties we lose when an
implementation violates them."
  -- from http://lists.w3.org/Archives/Public/www-tag/2002Apr/0303.html

Fielding's notion of REST is relatively easy to come to grips with, because
it's really all described in his thesis (albeit quite informally).

The other notion of REST is much more prescriptive, and is really close to
being the baseball bat notion which Roy refers to (I might put that a little
differently in public).  People like Mark Baker and Paul Prescod have
promoted this perspective.  They talk about "resource modeling" and want to
design applications to best fit the REST style in all respects, with an eye
towards supporting web services, i.e. supporting automated interaction
between systems that aren't necessarily designed with prior knowledge of
each other.  A short example of this kind of approach can be found here:

http://www.xfront.com/REST-Web-Services.html

This service-oriented (SOA) approach tends to emphasize XML, so as described
in the above link, it should be possible to e.g. request a list of parts and
get back an XML document with links to the available parts.  This approach
is geared to supporting richer clients than just browsers.  However, an
application which doesn't support this kind of thing and instead just
produces an HTML representation of a parts list - or perhaps doesn't even
give you a parts list, but lets you perform searches - can still perfectly
RESTful, it's just not particularly service-oriented.

The SOA approach tends to use REST principles much more strongly as a way to
dictate application design - it might be fair to call it "extreme REST", and
I think I've even seen someone like Prescod use that term.  I think there's
some justification for this approach, given the requirements of SOA, which
are more stringent than for standard browser-based apps.  However, the
design principles in this area are even less well-specified than the basic
REST principles.

* * *

Here are some of the better links I'm aware of:

Roy Fielding's thesis:
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
In particular:
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

There's the REST wiki:
http://rest.blueoxen.net/cgi-bin/wiki.pl
Useful topics on that wiki are ShortSummaryOfRest, RestArchitecturalStyle,
and ResourceModeling.
More tangentially, there's StateMachineAsHypertext and RestGoesToMaui.

Here's an article "Implementing REST Web Services: Best Practices and
Guidelines":
http://www.xml.com/pub/a/2004/08/11/rest.html

What is Service-Oriented Architecture?
http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html

This page has some good bullet points buried in section 2.1:
http://www.rexx.com/~dkuhlman/rest_howto.html

I'll quote the most important ones here:

====
* Everything is a resource. The client/user requests a resource. The Web
application delivers (the representation of) a resource. Even submitting
information is done via requesting a resource. (For example, the user might
submit information by requesting a form (the representation of a form
resource), filling out the form, then requesting the updated resource by
clicking a link in the form to submit the form.)

* Every resource has a URI. Think of the design process as determining which
things to name. URI's are the names.

* The application produces representations, not resources. Furthermore, for
any given resource, your application can expose multiple representations,
for example, HTML and XML representations and even multiple HTML or multiple
XML representations. Think of a representation as the content you generate
from a resource; the representation/content is what you send to the
client/requestor.

* State is carried on the client, not the server. One implication of this
guideline is that each request from a client must contain all the
information needed by the application (server) to satisfy the request.
====

The fourth bullet is the one with obvious implications for continuations in
REST.  REST's goal in carrying (session-specific) state on the client is to
minimize server load and maximize flexibility, e.g. it isn't necessary for
requests to go to a particular server, so load-balancing can be more
efficient.

>From a continuation perspective, REST encodes continuations as URLs and/or
HTML forms and embeds them in the pages sent to clients.  My point #1 about
continuations and REST is that recognizing the existence of these
continuations in REST systems can be helpful in the design of applications,
and particularly in designing a web application framework.  A framework can
provide continuation support at a conceptual level, which happen to be
serialized as URLs and web forms.  Once you've done that, the actual
representation of the continuations isn't that important to the application,
which opens up some possibilities.

Your dastardly plan worked, I think I just wrote part of an introduction...
;)

Anton