users@jersey.java.net

Re: [Jersey] What HATEOAS actually means

From: Mark Derricutt <mark_at_talios.com>
Date: Thu, 18 Feb 2010 08:26:06 +1300

Markus,

I was just rereading your post [1] and had ( to me anyway ) a sort of
epiphany, reading Roy's quote:

"The application state is controlled and stored by the user agent …
freeing the server from the scalability problems of storing state …"

It struck me that this is specifically APPLICATION state, and not
RESOURCE state. The thought that occurred was that application state
remembers how you arrived at a certain resource, what windows/objects
you might have open, how things gets sorted etc. etc.

But what about the state of a resource. In the case of a long running
work flow process that might be months from start to end, with
involvement of multiple users/clients, the resource state is
controlled and stored by the server agent, not the client.

My thought would be that with HATEAOS, any client connecting to the
system during this work flow would have all the information the need
returned from the server to participate in that flow, regardless of
how they joined it.

I must download the dissertation again and reread it, but I don't see
anyone talking about RESOURCE state, only APPLICATION state.

Any thoughts?



[1] http://weblogs.java.net/blog/mkarg/archive/2010/02/14/what-hateoas-actually-means
-- 
Pull me down under...
> agreed. Actually I didn't move the posts but changed the team, after
> learning about the "Link" header from Mr Fielding. ;-)