[PRL] REST?

Joe Marshall jrm at ccs.neu.edu
Wed Feb 16 10:33:05 EST 2005


Mitchell Wand <wand at ccs.neu.edu> writes:

> Hmm, looking at LtU, I found a discussion that talked about REST APIs
> vs PITA APIs.  I finally found that PITA was an acronym for Pain In
> The A**, but that REST was the name what appears to be the Web Design
> Pattern du Jour. (or maybe the "Distributed Software Architecture" du
> Jour). 
>
> Anybody here know about this and how it fits into the PLT conception
> of web services?

>From what I understand, the `REST' approach is all about `avoiding
saving session state on the server'.  Each response from the server
contains (a representation of) the entire session state and each
request re-transmits that state.  This makes synchronization easy and
it scales well to `server farms'.

The PLT approach, so far, is antithetical:  the entire session state
is saved on the server.  (Greg's work on reifying web continuations
will address this.)

But web services pose a lot of problems and neither the PLT approach
nor the `REST' approach solve all of them.  The root problem is this:
http's `stateless' transmit/receive model slices the program logic at
a truly inconvenient point.  The web client is essentially servicing a
remote procedure call and the web server is awaiting the result in
order to invoke the continuation.  The process state is distributed
between both the client and the server and must be resynchronized at
the next request.  (Alan Bawden's dissertation contains some
intriguing ideas suggesting that state arises when we partition
logically self-referential structure in this way.)

The `REST' approach suggests moving all the process state to the
client.  With no state on the server, there is nothing to synchronize.
The added benefit is that any server is as good as any other, so
server replication works for increasing availability.  The problem
with the `REST' approach is that while it suggests a strategy, it
offers no help in *implementing* that strategy.  It's easy enough to
say `put all the state on the client', but how does one go about
*finding* all the state?  Once found, how does one separate it from
the `stateless' part of the programming logic?  How does one restore
it when it is time to invoke the continuation?

There is another big question:  what counts as state?  The `REST'
approach differentiates between the `session state', that it says
should reside on the client, and `resources', that it says should
reside on the server.  But the `resources' include things like
databases and file systems, which are clearly objects with state!


The PLT approach to web services addresses the same fundamental
problem --- the inconvenient partitioning of the program logic --- by
using advanced programming language constructs to model the
interaction.  The programmer can simply ignore the fact that procedure
calls are distributed among two machines.  The state that arises from
the partitioning of the control flow is hidden within the partitioning
mechanism.

The PLT approach finesses the problems of locating, extracting, and
restoring the interaction state, but this comes with a cost.  The
state resides in the continuation, and the continuation resides on the
server, but references to the continuation are distributed in fairly
uncontrolled manner.  The server cannot free the resources associated
with a continuation until it knows that no references to that
continuation exist, but since http is a client-driven protocol, there
is no way for the server to probe for references.  Furthermore,
interactions with a web service are tied to the single server that is
storing the referenced continuation.


Anton van Straaten's suggestion at LL4 was that these two approaches
could be unified.  Since continuations are objects with indefinite
lifetime, they are more akin to the `resources' in a REST model than
to the `state'.  He suggests that the problems with the PLT approach
with regard to the lifetime of continuations and the way sessions are
`stuck' on one server can be solved by applying the techniques of
web resource management.  He didn't, however, give a concrete
suggestion of how a continuation captured by single PLT server in the
course of a web interaction might be rapidly replicated amongst the
thousands of servers in a `web farm'.


Greg Pettyjohn is investigating a different approach.  By reifying the
continuation (and all its attendant state), one can package it into
the web response.  The next client request can go to any server which
will then un-reify (reflect? realise?) the continuation and proceed.
This, too, unifies the PLT approach with the REST approach, but has
the important advantage that it automates the management of the
session state yet still hides that state with the usual language
flow-control mechanisms.

This approach again raises the question of what counts as state.
The *entire* continuation of a process includes the web server itself
and even part of the operating system!  The *entire* state of the
continuation includes any reachable, mutable object in the process and
stateful operating system supplied resources such as the file system.
Putting `session state' on the client is good, but `shared state'
should not be replicated.  The boundaries between the two are not
always clear.






More information about the PRL mailing list