[Seaside] Re: Seaside and REST

[Boris Popov]

Andreas,

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

Cheers!

-Boris

-- 
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

boris at deepcovelabs.com

CONFIDENTIALITY NOTICE

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

Thank you.

> -----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,
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
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside