Reputation: 23078
I have read about REST. When I had an overview of Lift, it seems that Lift:
Lift's idea of statefullness seems distinct from REST and kin. What exactly is Lift's state idiom? Why does it need server affinity? Does it become a minefield if we deviate from a fixed idiom?
How would it come to play in (and become an advantage) in this hypothetical concurrently-edited spreadsheet:
An update: dave commented on the exact reason for server affinity: here and here. Turns out FourSquare, very heavily trafficked site uses exactly this method.
Upvotes: 3
Views: 219
Reputation: 497
This is discussed in Lift in Action as it happens. The primary reason for statefulness is security: Lift is heavily dependant on in-memory state for security features like the function-mapped GUIDs on page controls. In addition, you'll find that frameworks claiming to be stateless and doing anything but pure REST are actually doing a pretty bad job at being a stateful framework: typically that involves round tripping state into cookies or serialising it into a hidden form field. Both of those techniques are used by popular frameworks (Rails, .NET, Play etc).
Moreover, it turns out that keeping things in memory is pretty useful as it means that each request doesn't have to reinitialise things like database connections and so forth. It also allows for some very nice features like Lift's comet support.
Hope this helps.
Tim
Upvotes: 2