For sure: keep all "application" state all you want and where you
want. I dont think that what Roy F. wrote in his dissertation goes
against that at all (And I dont think the Restlet framework forces you
to do that either).
The only thing I read from that quote is that REST is stateless with
respect to the communication between client and server (".. all the
information necessary to understand the request...") and that in my
opinion is very important and does not prescribe where application
state should be stored.
- Yuri
btw: why in hell does gmane web interface forces one to only write
lines no more than 80 characters? What a pain...
> Rob Heittman wrote:
> >
> > There's a massive amount of er, what did you say, "dry theory and
> > voluntary speak" on the question of sessions and continuations
> > vis-a-vis REST. Unashamed, I'll add more.
> >
> > The rub here is adherence to Fielding's "Stateless" constraint (5.1.3:
> > "each request from client to server must contain all of the
> > information necessary to understand the request, and cannot take
> > advantage of any stored context on the server. Session state is
> > therefore kept entirely on the client.") This is a good thing for the
> > underlying architecture of the WWW, but a largely irrelevant thing to
> > higher level application design. Keep state all you want and where
> > you want, if it's appropriate to your problem domain.
> >
> > Yet there it is; the seminal document defining REST says, in a big
> > booming voice, *** REST Is Stateless ***. In a framework called
> > "Restlet" is there any way to encompass the establishment of
> > server-side state without incensing the peanut gallery? It's not my
> > baby, I can't say. But I'd guess No, unless somebody brings in a
> > written excuse from Dr. Fielding.
> >
> > > Given the above, I think the 'resourced' way of keeping some
> > > (admittedly) application flavoured state up at the server would be to
> > > create temporary 'resources' that allow to store some use-case related
> > > state.
> >
> > The transient resource behavior you describe is neatly done at a layer
> > below Restlet. We, for example, keep resources in a virtual,
> > versioned filesystem (VFS) that uses WebDAV semantics; a "transient"
> > property combined with an expiring lock provide the information needed
> > to manage and reap transient resources. This isn't glued to Restlet
> > especially well yet (it's a general Java facility that predates our
> > Restlet experience), but it's why we're working on getting a full set
> > of RFC 2518 semantics into Restlet and making a proper Client
> > connector for our VFS.
> >
> > We plan to share it as commercial open source when it's ready. "REST"
> > won't be part of the name, so Fielding's legion of zombies doesn't
> > carry torches to our door. :-)
> >
> > - Rob
> >
>
> --
> Justin Stanczak
> Stanczak Group
> 812-735-3600
>
> "All that is necessary for the triumph of evil is that good men do nothing."
> Edmund Burke
>
