Julio Faerman wrote:
> Hello all,
>
> In a session-less application, i would need to store state in the
> client. At least a pointer (ID, URI, UUID, etc), for the remote server
> to retrieve my data. Let us consider the regular browser + javascript
> client and the problem of keeping state across pages.
> As i can't count on posted forms, i think a "postback" approach is out
> of question to store such reference.
> I suppose cookies would have the same drawbacks as the usual http
> session, plus "reinventing" the wheel.
> A client-side storage, e.g. google gears, could handle it, but that
> opens another can of worms.
> So that leaves me with an ugly hack, suck as storing stuff on
> window.name or something like that.
>
> Am i missing something? Have anyone found good solutions for such problem?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
RESTafarians (I suppose I'm going to get lumped into that category now
:-) will suggest that you include URIs in your initial response that the
client can use to access whatever they will need later. There's a
phrase from the initial thesis that defined REST related to this
concept: hypermedia as the agent of state. In other words, for every
state change that the client can make in the system, the server can give
it (in the representation of the current state) a URI that can be called
to perform that state change.
Let's take the particular case of a customer list with URI
"{appname}/customers" (contextualized by the server already based on the
username in the HTTP Basic credentials), to return a nice HTML table.
But within the table, you want a link or button that does a popup that
* does an XMLHttpRequest link to the server to grab more details for
this customer
* displays a popup with the extra details
So, how does your popup know how to get the extra data for each
customer? The initial HTML response can include a link for each of the
displayed customers -- it will probably be of the form
"{appname}/customers/{customerid}" but the client should not need to
know how it is constructed. Then, it's straightforward for the client
side to do a simple XHR request to get the needed data.
Same principle applies to things like adds, updates, and deletes ... the
initial displayed page can include URIs for the client side to use when
initiating these actions (which would typically be a POST, a PUT, and a
DELETE for these three actions).
In other words, the state is embedded in the current representation, and
state changes are performed by making a RESTful call to one of the URIs
included in that representation.
Craig