[Seaside] Re: Seaside and REST
boris at deepcovelabs.com
Thu Mar 29 17:42:48 UTC 2007
See my earlier messages. It's completely up to you, as you get to choose
whether to use anchors (GET) or forms/buttons (POST) when you put your
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
boris at deepcovelabs.com
This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
> -----Original Message-----
> From: seaside-bounces at lists.squeakfoundation.org [mailto:seaside-
> bounces at lists.squeakfoundation.org] On Behalf Of Andreas Raab
> Sent: Thursday, March 29, 2007 10:39 AM
> To: Seaside - general discussion
> Subject: [Seaside] Re: Seaside and REST
> 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,
> > 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
> 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
> > NOT use, POST or GET? IIRC they use both and the choice depends on
> > 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
> >> These methods ought to be considered "safe". This allows user
> >> to represent other methods, such as POST, PUT and DELETE, in a
> >> way, so that the user is made aware of the fact that a possibly
> >> action is being requested."
> > Then, how would you access a constantly changing "document" resource
> > like a Croquet application running elsewhere, with HTTP. HTTP
> > methods where invented with "a resource is a file and the version
> > 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
> 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.
> - Andreas
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the seaside