Felipe,
thank you for chiming in.
Unfortunately I do not see that this is a better example for statefulness or
HATEOAS than the previous cart example: First, you can handle your workflow
solely on the basis of the "Allows:" header at the resource. Second, you're
talking about resource state but not communication state: What you are
describing is not *per-client* but *per-resource*, as *all clients* would
ever see the same status (if I understand you example correctly, it depends
on the resource what a client sees, so it is obviously the same for each of
them). But what was under discussion was stateless and HATEOAS, which both
deal heavily with the state *per client*, especially with *different* states
for client accessing possibly the same resource.
So let's find another example... (thinking)... oh, I know one that virtually
all of us know and which is rather simple:
When you're going to an ATM ("Cash Automate"), and you're wife does the same
*at the same time for the same account*, both ATMs will share one state *of
the resource* (your account obviously has just one balance, not a different
balance for each client).
But each ATM has a it's own state *of communication / workflow* (i. e.
*state per client*): Yours might be in the state of asking for the
passphrase ("PIN") currently and has neither shown your balance nor paid off
money so far, while your wife's already is in the state of payoff - she
already entered her PIN, noticed the balance, and typed in the wanted
amount.
This clearly shows (I think) well the difference between the state of the
resource, which obviously is stateful, as it will not change between the
workflow steps of typing in the PIN, showing the balance, typing in the
amount, and paying of the money, but just between the workflow instances,
and in this particular example is stored server sided, to the state of the
communication / workflow, which is transitioned from workflow step to
workflow step, but is not stored on the server but solely known to the
current ATM's own session, and so is a per client status. That status is of
no interest after the workflow instance ("getting money from the machine by
YOU" compared to "getting money from the machine by YOUR WIFE") is over,
also it is of no interest for a different earlier / later / parallel
workflow instance.
Obviously state *of resource* SHOULD be kept centrally on the server (and
such is "stateful", even more it is a "shared state") to allows both
partners to share the same balance and to prevent people from getting more
money than there is left on the account (in fact, it is really only SHOULD
but not MUST, as we could also provide a shared-nothing architecture where
one ATM broadcasts your disposal to all others by some kind of event message
and there is no server at all).
But state *of communication / workflow* (i. e. whether you already entered
your pin, have seen your balance, typed in the amount, or already pulled the
banknotes) is not necessarily stored on the server. Moreover, storing it on
the server would not bring any benefit, but would be a huge burden for the
server. THAT information is what the "stateless" / HATEOAS discussion
actually is about, besides our intermediate discussion about the usefulness
of Amazon's long-term carte: What "stateless" means here is that the state
*of a single client* is not to be stored on the server unless there is a
business requirement, to safe scalability.
HATEOAS is about both, *per client* AND *per resource* state, as it must
send the correct URIs. So, if you balance is low, *both* clients wouldn't
find a "payoff" link, as *no* client is allowed to draw money. But whether
or not your client will receive a URI for "show balance" is not dependend of
the shared resource's state (balance), but solely on your own client's
correctly or incorrectly typed in passpword.
I hope that this example is simple and unambiguous engough that we finally
now all agree upon what the word "stateless" means in the context of REST
and HATEOAS? :-)
> -----Original Message-----
> From: Felipe Gaścho [mailto:fgaucho_at_gmail.com]
> Sent: Sonntag, 21. Februar 2010 10:36
> To: users_at_jersey.dev.java.net
> Subject: Re: [Jersey] RESTful Ordering (was: JAX-RS == REST? Or not?
> (was Re: [Jersey] What HATEOAS actually means))
>
> That's my PUJ example :)
>
> I have this academic competition, with "competition phases"...
>
> So, I have professors submitting student's homeworks for a
> competition, and each competition has the following phases:
>
> 1) call for papers
> 2) evaluation
> 3) history
>
> So,
>
> 1) During the call for papers, a professor can submit a homework, or
> patch the homework, delete, etc (homework CRUD). When the competition
> changes to the evaluation phase, no more changes are accepted in the
> homeworks, so the method PUT and POST should be "disabled" in the
> homework resources.
>
> 2) During the evaluation, the "evaluators" can apply grades to the
> homeworks.. They can also review their grades. methods PUT, GET,
> DELETE and POST are available to the homework grades resource.
>
> 3) When the competition finishes, it goes to the history phase, and no
> more changes are acceptable in the homeworks (evaluation, patches,
> etc..). The resources supports only GET methods in this phase.
>
> Notice that I have two distinct workflows here:
>
> 1) the resource workflow, where a change in the resource produces its
> feasible next states as side effects.
> 2) the application phases, where an external action (usually the
> competition owner presses a button) changes the state of all resources
> regarding a competition.
>
> Considering the competition also as a resource, I have a change in the
> state of a competition with side effects in other resources. So it is
> not only a matter of changing the resource representation, but also to
> manage the impact of that changing in other resources.
>
> I have an slide representing this problem in this presentation:
> http://www.jfokus.se/jfokus/preso/jf-10_DomainDrivenRESTWeb-
> Services.pdf
>
> Please let me know if this problem is suitable for your discussion.
>
> I have also some code implemented about that, like:
>
> ------------- load competitions:
>
> XML/JSON: http://fgaucho.dyndns.org:8080/arena-http/competition
> JSONP: http://fgaucho.dyndns.org:8080/arena-http/competition/jsonp
>
> ------------- load homeworks:
>
> XML/JSON: http://fgaucho.dyndns.org:8080/arena-
> http/homework?competition=PUJCE-09
> JSONP: http://fgaucho.dyndns.org:8080/arena-
> http/homework/jsonp?competition=PUJCE-09
>
> * if you don't include the 'competition' parameter, it will load all
> homeworks.
>
> and I have also some write operations implemented..
>
> It is consumed by clients like:
>
> http://fgaucho.dyndns.org:8080/arena-dwr/
> http://fgaucho.dyndns.org:8080/arena-jsf20
>
> the code is fully available from here:
>
> http://kenai.com/projects/puj/pages/Arena-dev
>
> but it is still a work in progress... so be nice to tell me the missed
> points :)
>
> regards,
>
> Felipe Gaścho
>
>
>
>
> On Sun, Feb 21, 2010 at 10:14 AM, Markus Karg <markus.karg_at_gmx.net>
> wrote:
> > Tatu,
> >
> >
> >
> > no doubt about that. If you business demands storing a resource, REST
> will
> > not prevent you from doing so. But as you said, then this is because
> of it's
> > resource state, not of it's conversational state. The conversational
> state
> > still must not get stored on the server. So for sake of clarity,
> let's not
> > further use the carts example, as it would mislead readers. We should
> fina
> > an example where undoubtful the conversation state will never get
> part of
> > the resource state just be redefinitio of the business scenario. ;-)
> >
> >
> >
> > Regards
> >
> > Markus
> >
> >
> >
> > From: Tatu Saloranta [mailto:tsaloranta_at_gmail.com]
> > Sent: Samstag, 20. Februar 2010 20:07
> > To: users_at_jersey.dev.java.net
> > Subject: Re: [Jersey] RESTful Ordering (was: JAX-RS == REST? Or not?
> (was
> > Re: [Jersey] What HATEOAS actually means))
> >
> >
> >
> >
> >
> > On Sat, Feb 20, 2010 at 12:09 AM, Markus Karg <markus.karg_at_gmx.net>
> wrote:
> >
> > Anyways, their storing of carts content of their servers was a
> business
> > decision, not a technical one. ;-)
> >
> > Agreed. But I think it is an interesting case to consider -- I am
> sure that
> > persistency (and thus statefulness) of resources is a must for many
> systems.
> > And that it is necessary to separate resource state with
> session/transaction
> > state. I don't think REST would preclude former, but at this point I
> would
> > not be entirely surprised to be convinced otherwise. :-)
> >
> > Actually come to think of that, I can see why someone might think of
> > shopping cart as conversation state... and others as more of a
> resource. I
> > guess that is modeling choice really.
> > And also a practical thing: if it is part of conversation, you can
> have
> > multiple concurrent sessions (open a new browser window, get a
> different
> > cart); or just a single shared one per account.
> >
> > FWIW, for retailers like Amazon this is obviously a must feature; not
> just
> > shopping cart but wish lists and such. Although it is good to get
> immediate
> > sales, probability of a later purchase is probably high (I don't know
> the
> > ratio, nor could divulge if I did -- this is just inferred from
> public
> > information :) ).
> >
> > -+ Tatu +-
> >
>
>
>
> --
> ------------------------------------------
> Felipe Gaścho
> 10+ Java Programmer
> CEJUG Senior Advisor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net