[Seaside] Re: Seaside and REST

[Colin Putney]

On Mar 29, 2007, at 10:38 AM, Andreas Raab wrote:

> 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?

You can get even more philosophical by considering continuations to  
be "resources." The theory behind HTML and HTTP is fine, but in  
practice you can't always live up to it. One of the limitations has  
been mentioned already - that you can't specify that a link should  
generate a POST request when the user clicks on it. Conversely, GET  
requests can't upload data in the body of the request; it has to be  
encoded in the url. This means that you must use POST to upload  
significant amounts of data, regardless of the semantics of a request.

Seaside doesn't have "special rules" but it does (by default) use a  
convention to make this stuff a little safer. Normally, the  
transition from one page to another is split into two request- 
response cycles. The first triggers the callbacks associated with the  
link or form elements, and Seaside sends back a 302 response,  
redirecting the browser to another url. The second request triggers  
no callbacks and is a "pure" HTTP GET. Seaside sends back an html  
representation of the page in its new state. That page can be  
reloaded as much as you like with no side effects.

Seaside is a set of compromises that takes a lot of the pain out of  
writing web apps. For web apps - software that uses the web as it's  
user interface - it's a pretty good compromise. It's not a good  
compromise for dynamic websites, or RESTful web services or similar  
things.

Hope this help with your decision,

Colin