[Seaside] Re: Seaside and REST

[Andreas Raab]

Lukas Renggli wrote:
>> * RESTful URLs: Philippe pointed me to http://www.lukas-renggli.ch/blog/
>>   which discusses the use of RESTful URLs in Pier. Looking at it I found
>> the dazzlingly cryptic method PRPierFrame>>initialRequest: and gave up
>> on the idea for the time being ;-)
> 
> The thing that Pier is doing in #initialRequest: has absolutely
> nothing to do with RESTful URLs. In Pier this method is used to setup
> the dynamic component tree specified in the environment page of the
> wiki.

Sorry if I got this wrong - Philippe seemed to imply in his post that 
such a setup is done in #initialRequest: and I just didn't get what the 
code in PRPierFrame had to do with setting up REST urls ;-)

> The thing that parses the URL is PRPierMain>>#start: and friends.

Thanks, I will look at this.

>> Could someone perhaps give a brief outline of what needs
>> to be done to support RESTful URLs in Seaside that both,
>> goes well beyond "it can be done" and stays well short of
>> PRPierFrame's implementation? ;-)
> 
> WABrowser

Yes, I had seen this but there were some aspects that weren't clear to 
me so I was wondering how they would be addressed in a real application 
(which also led me to PRPierFrame>>initialRequest: btw).

>> * GET vs. POST: One of the things that confused me about the simple
>> counter example already is that it uses POST instead of GET - isn't GET
>> supposed to be idempotent as well as not modifying the requested 
>> resource?
> 
> Frankly, if you are thinking about URLs and POST vs. GET, you should
> probably not use Seaside.

Frankly, giving a non-answer like this isn't exactly helpful. If you 
think that there is something wrong with a basic assumption you should 
enlighten me. But the last time I checked, Seaside utilized HTTP and 
HTTP has some very clear rules (see [1]) which state explicitly:

	"In particular, the convention has been established that the GET and 
HEAD methods SHOULD NOT have the significance of taking an action other 
than retrieval. 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."

State changes (like in the counter example) seem to signify "an action 
other than retrieval", no? Now, you may choose to ignore these rules but 
"SHOULD NOT" in an RFC has a much stronger meaning than "it's okay to 
ignore if you feel like it" [2]. That's why I've been asking the 
question. And I think the robots issue is a real one, too. Or do Seaside 
apps somehow, magically, never get indexed? Can they even be indexed in 
any meaningful way?

Cheers,
   - Andreas

[1] See http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1

[2] See http://www.ietf.org/rfc/rfc2119.txt
    SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
    there may exist valid reasons in particular circumstances when the
    particular behavior is acceptable or even useful, but the full
    implications should be understood and the case carefully weighed
    before implementing any behavior described with this label.