[plt-scheme] Implementing web services

John Clements wrote:
> 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.

Yes, although I think there's room for a REST-aware framework to make it 
possible to write something other than manually CPSed code.  Such a 
framework would presumably impose some requirements on the application 
architecture, more so than the send/suspend approach.

>> 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.

Yes.  One reason I became interested in REST is because some of the 
applications I work on tend to naturally gravitate towards option 1.

The reason for this goes back to Matthias' observation about the 
functional nature of REST.  In financial systems with any kind of 
integrity, there's no mutation of transaction data: new information is 
recorded by adding transactions.  Even if an old transaction turns out 
to have been wrong, it is corrected by recording new information, not by 
modifying the original data.  This is typically managed using a 
bi-temporal approach[*], in which transactions are recorded with both an 
effective time (the time at which they "actually" occurred) and a 
recorded time (the time at which the application became aware of them).

So there's "lots of state" in that every input to the program over its 
entire lifetime is recorded, so any report that was ever produced can be 
reproduced.  Further, requesting a particular report caches the results 
(using more state), so that future requests for the same report (which 
are guaranteed to happen, for the systems in question) will be quick.

REST is a very natural way to provide an interface to such a system, and 
can provide useful design guidelines.

Something similar applies when it comes to workflows across an 
enterprise - you want to keep track of who did what to which data, when. 
  The state of some work in progress is just the sum of all the relevant 
events up to that point, and the same approaches apply as above.

> Apologies for time spent restating the obvious?

To keep you company, I have just spent time restating that a system's 
states can be constructed from a history of events within that system. 
But if these things were so obvious, more people would write better 
applications...

Anton

[*] http://www.martinfowler.com/ap2/temporalProperty.html and
     http://martinfowler.com/ap2/timeNarrative.html