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