[Seaside] Re: SeasideRest and complex structures

Norbert Hartl norbert at hartl.name
Sat Apr 23 08:17:53 UTC 2011

Am 22.04.2011 um 20:49 schrieb Fritz Schenk:

> I have difficulties with the concept of REST alongside Seaside. According to 
> Fielding's dissertation Chapter 5.1.3, there cannot be any session state kept 
> by the server component.
> In my opinion, what you are after is clean URLs as described in 
> http://onsmalltalk.com/clean-urls-in-seaside.

The ST in REST denotes exactly this. State is always transferred to the client in order to enable it to do any action this state/page provides without any external source. As REST is an architecture this approach would get you the maximum out of it. This works best if state (context) is transferred from the client (sender) to the server (receiver) on a specific URL (method, although an URL encodes receiver and method). A big point in the architecture is orchestration. An invocation of an action includes e.g. the routing of the call and much more. 
It works especially good if you have an resource centric view. The HTTP verbs map to CRUD operations and URIs act like IDs. On the other hand the application/dynamic/service view is kind of weakly defined by fielding. GET and POST are the ones that not only deal excusively with resources. While POST is explicitly not about resources GET lives a double life. Why? Because REST is an architecture (and not a service description) upon you base your application/service and there is no way predescribing or forcing an application/service into one distinct scheme.
I think it is often misunderstood that not being in fieldings description does not mean it must not exist. There is a place for server side state you should just avoid it where possible. 
A good idea in such discussion to disambiguate the topic is to talk about RESTful URLs instead of just REST.

The funny thing about it is that REST has ST in it for a reason. I think that the REST architecture and smalltalk both think of the web as a big virtual machine. So it is very interesting to see where they fit together best.

my 2 cents,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20110423/06d0f460/attachment.htm

More information about the seaside mailing list