[plt-scheme] Implementing web services

On Aug 14, 2007, at 3:15 AM, Anton van Straaten wrote:

> John Clements wrote:
>> Someone tell me I'm mistaken: it appears to me that REST is  
>> simply  continuation-based web programming with the additional  
>> restriction  that there be only a finite set of possible  
>> continuations; the  easiest way to achieve this is to allow only  
>> tail calls.  So in  principle, cps-ing achieves REST.  In common  
>> use, however,  maintaining a continuation as a POST-style argument  
>> is un-idiomatic,  slow, and insecure, so you need to severely  
>> restrict the possible  size of the continuation argument.
>> Is that a fair summary? Did I just recapitulate the slides I skimmed?
>
> I'd say that's correct as far as it goes (in principle), but  
> there's more to it than just restricting the possible size of the  
> continuation argument.  The ideal goal (often not achieved) for a  
> REST app is to structure it so that continuations can be  
> represented as nothing more than URLs which don't depend on any  
> session-specific state.
>
> If you can email a URI to your friend and have it work for her, and  
> if it continues to work in the future, then that's a pretty RESTful  
> URI. If you take that ability as a goal throughout an application,  
> it implies all sorts of things about the structure of the  
> application and its continuations.

Right: in particular, it implies that you must CPS the code yourself,  
after which the implicit continuation is completely nonexistent. (I'm  
using the term "implicit continuation" to refer to the language's  
program context, as opposed to an explicitly maintained continuation  
argument).  I think we're in agreement.

>
> To use a simple concrete example, say we extend the "add.ss"  
> example servlet to maintain a running total of the numbers that  
> have been entered so far.  I then patiently sit at my browser and  
> add up a few hundred numbers.  Now I want to bookmark one of the  
> result pages, or add its URI to a wiki, or email the URI to a  
> colleague.
>
> With a continuation-based server, one runs into a slew of issues at  
> this point:
>
> * The dependency on a POST request prevents its use in this way.   
> POST requests are OK for submitting data, but in REST terms the  
> resulting page should be identified only by its URI.  You can of  
> course address this with the post-redirect-get pattern.  This can  
> of course be done easily enough, but it points out one way in which  
> applications have to be structured to support REST.
>
> * The continuation (and its URI) isn't persistent - e.g. it can  
> time out, and it doesn't survive server restarts.  This is a big  
> one which effectively eliminates non-persistent continuations as a  
> candidate for development of REST apps.
>
> * In a slightly more sophisticated application which supports user  
> logins, an identifier for the logged-in user would typically end up  
> being stored in the continuation, unless you take active steps to  
> prevent it.  That information, along with various other kinds of  
> session-related info, is orthogonal to the resource being  
> referenced by a URI, and you don't want the URI to somehow  
> "contain" this information and thus either limit its usefulness, or  
> even compromise security.
>
> * etc.
>
> If you think of REST as identifying a set of tradeoffs (at least,  
> Fielding's paper does that), and giving a name to a region in that  
> tradeoff space, then continuation-based servers as currently  
> conceived tend to overlap the edges of that space, at best.   
> Although in principle, the CPS+lambda-lifting+defunctionalization  
> transformation gets you to a similarly structured application,  
> that's not enough by itself.

In my mind, REST doesn't so much offer an alternative to this; it  
just says "don't do that."  In your example, I think that the  
idiomatic REST solution to your proposed problem (adding up a bunch  
of numbers) would be either:

1) use lots of state, or
2) just don't do that.


Apologies for time spent restating the obvious?

John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2223 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20070814/c40ff58b/attachment.p7s>