[Seaside] Re: Seaside and REST
andreas.raab at gmx.de
Thu Mar 29 17:38:49 UTC 2007
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.
More information about the seaside