Walking into the middle here. Lukas Renggli on using Seaside for a RESTful web app. REST (Representational State Transfer) assumes that there's a well known URI for any point. Seaside is somewhat in conflict here, as Seaside URIs don't represent an endpoint, but a current application state. My take on this - Seaside solves one set of problems, but not all problems. For instance - I don't think it works particularly well for a blog, since a blog consists of nothing but well known end points.

However, this little talk provides a framework for url rewriting that allows Seaside to dabble in the REST world. That's probably a good thing, since it extends the space of applications for which Seaside can work. The state issue is solved by having a new session (and thus, a new set of domain objects) forced when returning. That's not a requirement, btw - the framework allows for session maintenance if you really want it.

So what this allows is the external appearance of a RESTful application with a Seaside back end. The complexity can get out of hand if the back end domain model is very complex.