[Seaside] Re: Seaside and REST

[Andreas Raab]

Hi Klaus -

Klaus D. Witzel wrote:
> Besides of that, the counter in the Seaside counter example is *not* 
> stored (as would be suggested by POST) but it is incremented. Doing 
> incremental changes to a living object is not addressed by any HTTP 
> request method ;-) For example, all WebDAV resources and Web2Mail 
> scripts are considered to be dead (in the sense of a stateless, always 
> repeatable request+response scenario).

Which indeed they are. Buy my point about the counter example went of 
course a little deeper. I can see the counter as stateless merely by 
assuming that we have a platonic space of integer numbers where plus and 
minus are retrievals ;-) However, that gets really hard when we get to 
persistent state that can't be undone easily. Or when one deals with 
files directly. Does Seaside have "special rules" for making such 
modifications or are all of these presented as GET nevertheless?

> Another illustrating use case is HTTP-tunneling. What method SHOULD they 
> NOT use, POST or GET? IIRC they use both and the choice depends on what 
> method allows *huge* amounts of bytes transfered upstream (POST) and 
> what not (GET).
> 
> [this is just from experience, no offense intended.]

None taken. That is a great question. What is "best practice" these 
days? Just use whatever you feel like? Whatever works most efficiently?

>> These methods ought to be considered "safe". This allows user agents 
>> to represent other methods, such as POST, PUT and DELETE, in a special 
>> way, so that the user is made aware of the fact that a possibly unsafe 
>> action is being requested."
> 
> Then, how would you access a constantly changing "document" resource 
> like a Croquet application running elsewhere, with HTTP. HTTP request 
> methods where invented with "a resource is a file and the version and 
> quality of the file's content can be negotiated by a HTTP method" in 
> mind, IMO.

True, but for example, in Croquet we have that distinction constantly. 
We have, for example, a method #get: in code which (surprise!) is a pure 
retrieval, idempotent and safe ;-) And then we have future messages 
(think: POST) which modify the resource (object). And it makes perfect 
sense both conceptually as well as from a practical point of view.

Cheers,
   - Andreas