Stephan Koops wrote:
one of the main points of REST is, that there is no session state on the
server. If you want to have a session state, than you do not follow the
REST architecture style.
uh, yes, but:
observation 1- there *is* server side state in ReSTful apps. As Stephan
points out however it is not 'session state'. It should not be
'application state' but it is always and only 'resource state'
observation 2- there really is nothing that prevents resources to live
only for a certain period of time, nor is there anyone forcing you to
have them persisted on disk (although most people will think of them as
such)
See also an earlier thread in this group under the subject "session
debate" that allowed for some pragmatic helpfulness in this religious debate
http://restlet.tigris.org/servlets/SearchList?list=discuss&searchText=sessions+debate&defaultField=subject&Search=Search
And some added ideas to:
http://restlet.tigris.org/issues/show_bug.cgi?id=364
So the challenge in practice becomes to think about sessions (or even
directly the items you want to store in them) as being (temporary)
resources ;-)
A rough dump of what the rest-face of a TemporaryResourceRestlet would
look like: (just coming to mind)
POST ./ : creates a new temporary resource, allocates an id to it and
redirects you there (or offers the id in a neat response)
PUT ./{id}/{key} allows to store a representation in this temp resource
DELETE ./{id}/{key} would remove it again
DELETE ./{id} would remove the whole thing (all keys)
GET ./{id} shows the list of the available keys in this resource
an IMHO acceptable side effect of this GET (also by calling HEAD) would
be that some last-accessed-time is updated
With that a server-side clean-up mechanism could be envisioned to
automatically remove resources no longer in use (yes, that is meant to
sound like a session time out)
We could also associate these temporary resources automatically to
authenticated users
GET ./{user}/ : could list all temporary resources in place for this
user, obviously this would only be available to the actual authenticated
user (and thus not for temp resources created under a not authenticated
user)
This would be a mostly internally called restlet probably (riap://)
however modern AJAX apps might want to call upon it directly as well
since they could rightfully store the temp-resource-id in their
'application state' up in the browser. Extra benefit here is that this
ajax client would also be able to nicely DELETE the resource at some point.
Of course, when the luxury of such smart clients is not there, your left
to the old school tricks to 'keep the session state' going back and
forth between client and server. Cookies are at your own risk here, the
more ReSTy way of doing would be to have proper URI rewriting I guess
(hidden arguments in forms might work out as well)
To complete: As concluded already in the mentioned thread the worries
surrounding this kind of solution in a cluster environment should be
addressed by making sure that all servers in the cluster share the same
'resource state' (including the temp resources)
Being just 'resources' this issue should not be harder then sharing the
state of all other resources across the cluster (which needs to be done
as well)
regards,
-marc=
Jahid schrieb:
Hi,
Is there any session on server side? I was looking for session or
session type
something in API documentation. But I didn't fine any.
So the question is, is there any session object on server side? If
yes, what
class is that and how to use that? If no, then how we maintain have
some memory
bases data saving on server side?
Regards,
Jahid
