[Seaside] REST, bookmarkable URL's

[tblanchard@mac.com]

This was a problem with WebObjects too.

The WebObjects solution was to provide a second mechanism for hitting  
handlers directly called DirectActions.

A regular webobjects url looks like

http://server/cgi-bin/WebObjects/wo/ComponenetName/ 
sessionstateidkeystuffthatisugly

A direct action looks like  
http://server/cgi-bin/WebObjects/wa/ClassName/MethodName?queryArgsGoHere

Note that the wo vs wa specifies a different handler in the app server  
and thus you get routed to a handler that constructs an instance of  
ClassName, then calls MethodName with the request and response as  
arguments.

It seems to me that a big part of the fancy bit of Seaside is the state  
management - but you don't have any state with REST requests.
So I would guess you could do something like this for stateless  
operations.


On Thursday, January 2, 2003, at 04:02  PM, Stephen Pair wrote:

> I think this is definitely an issue that should be addressed in some
> way.  Consider that in Swiki.net, I need to follow the REST principles
> because my users need to bookmark Swikis, pages, downloads, etc.
> Seaside's current incarnation doesn't support that.
>
> But, I definitely do like the ease with which Seaside allows you to
> build web apps.  It's sort of like VisualWave without the windowSpec
> translation baggage plus support for the browser back button (at least
> to some degree).
>
> What I would like (and Avi and I have had some discussions about this)
> is the ability to "mount" Seaside's components on any arbitrary URLs.
> The Seaside component would be the "resource" (in REST terms).  Now,  
> the
> problem is then that the URL would immediately result in a forward to
> another non-bookmarkable URL that controls the user interaction.
>
> One way I thought that you could get around this would be to respond
> with one full-size frame that essientially hides the codified URL from
> the user (enabling them to bookmark the application's "mount-point"
> URL).  However, this doesn't satisfy the REST priniples in that you
> aren't responding with the actual resource, but rather a pointer to the
> actual resource in the form of a frame.  This would make it difficult
> for an automated interface to be able to fetch the contents of a
> particular URL.
>
> It is possible to do a "bookmark me" button in Javascript and that  
> might
> be a nice compromise.  Or, perhaps another possibility is to support
> both the "bookmark me" button, and a framed response.  You could also
> handle the automated interface by passign parameters in the URL (like
> ?auto=true&user=foo&pw=bar), which would disable the framed response  
> and
> could also provide an automated authentication capability (to avoid
> walking through web pages to handle authentication).
>
> One thing that is still happening in all of this is that any URL into a
> Seaside system is going to result in an HTTP forward response (which
> forwards to the codified session URL).  I think most HTTP clients
> (including things like wget) can handle this just fine, but I thought
> I'd mention it here in case anyone can think of a reason that this  
> would
> be an issue.
>
> - Stephen
>
>> -----Original Message-----
>> From: seaside-admin@lists.squeakfoundation.org
>> [mailto:seaside-admin@lists.squeakfoundation.org] On Behalf
>> Of Cees de Groot
>> Sent: Thursday, January 02, 2003 9:24 AM
>> To: seaside@lists.squeakfoundation.org
>> Subject: [Seaside] REST, bookmarkable URL's
>>
>>
>> Seaside (and in fact the app I'm working on myself) is in
>> conflict with REST because URL's don't define resources. I
>> vaguely recall that we had this discussion before - James
>> Robertson brought it up as an argument against packages like
>> Seaside (and, to be fair, VW's on VisualWave), and I couldn't
>> remember how the discussion was left over here.
>>
>> I was wondering whether it would be possible to have, say, a
>> 'bookmark me' button on a page which would add a bookmarkable
>> URL to the browser's links. That's a) a matter of Seaside to
>> interpret the URL, ask for a login if necessary, and then
>> move to the indicated resource, and b) a matter of Javascript
>> (is it possible to add bookmarks from Javascript?).
>>
>> -- 
>> Cees de Groot               http://www.cdegroot.com
>> <cg@cdegroot.com>
>> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F
>> E098 9E8B Cogito ergo evigilo
>> _______________________________________________
>> Seaside mailing list
>> Seaside@lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/listinfo/seaside
>>
>
> _______________________________________________
> Seaside mailing list
> Seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>