That is a very good point Marc is making. The way I think about it, that
REST is not really stateless :-) it requires state separation:
application state - always on the client (what page is the client on);
can use cookies fully client controlled
resource state - on the server (no cookies)
- if one needs session for keeping track of what page I am on now, client
needs to do it, for example by keeping it in the URI, header or in the
cookie.
- if you need to have a per user preferences, you need a user resource on
the server and manage the user resource state on the server.
- anything that changes the resource state must be kept on the server in
the resource representation
- if you need to do something like longer algorithm with multiple
interactions, define a resource corresponding the algorithm and manipulate
it with stateless REST interaction
Leshek
"Marc Portier" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
>
> 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
>>>
>>
>
