> in my scenario what I have similar to this are the grades..
>
> when an evaluator gives a grade to a homework, it see a different
> average result than other evaluator that loaded the grades but didn't
> made any change yet.. so two clients showing different information
> about the same resource (evaluation)..
In fact I doubt that: If I understand correctly, the grades are dependent on
the evaluator but not on the client. That means, if one evaluator comes back
at a later time at possibly a different terminal, he would still see the
grades he gave. If that is true, then the grades are not part of the session
state / client state, but part of the resource state -- as there will be a
grade resource then stored somewhere (possibly) on the server. I would agree
that grades are part of the session state, if they are visible solely on
that terminal for the time between session start and session end, but not at
a later time, and not on a different terminal.
> Other thing that bothers me is the authorization part: should the
> client loads the hypermedia links dynamically depending on the
> consumer role ?
Why would you like to do so? There is a smart solution in https (HEAD on the
URI, inspecting the Allows: header of the result). No need to reinvent the
wheel. The resource is not gone just because you currently have not right to
follow it. Nothing bad will happen if the client follows it using HEAD to
find out whether you are allowed to, and nothing bad will happen if the
client follows it unconditionally and the server rejects this attempt.
Regards
Markus
> On Sun, Feb 21, 2010 at 1:59 PM, Markus Karg <markus.karg_at_gmx.net>
> wrote:
> > 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
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >
> >
>
>
>
> --
> ------------------------------------------
> 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