Hi Paul, this is indeed a challenging task sometimes, but very interesting
:)
Migrating from imperative architectures to declarative ones (I consider REST
architectures to be declarative, when well designed) is something I'm
progressively learning, and finding it great. CRUD applications are trivial
to migrate, but some complicated non-CRUD applications offer a nice
challenge :)
The other thing I'm thinking a lot is about Resource Transformations.
Sometimes when a resource changes its state, several other resource should
be transformed as well. Duncan Cragg exposes a nice example of this in this
discussion:
http://duncan-cragg.org/blog/post/getting-data-rest-dialogues/
Borrowing his example, let's consider a product being sold on eBay. Let's
suppose the product can have 3 states: "Created", "On Sale" and "Sold". The
first state would be the resource's state right after creation, before its
owner puts it "On Sale". After the product is put "On Sale", other users can
make offers to buy the product. After receiving several offers, the owner
might decide that he wants to accept the best offer. Accepting the offer
would transition the product from "On Sale" to "Sold", mark the best offer
as "Winner" and mark all the other offers as "Loser".
We can see that some updates can be made on the Product without modifying
its state. For example, the owner could modify the description or the price
of the product, and these changes would not modify the Product's state.
However, when the owner accepts the best offer, the Product goes from "On
Sale" to "Sold". This a special update, that implies modifications on other
resources too (in this case, the Offers).
These special state transitions are what I call Resource Transformations,
and it's something that I'm still trying to find the best design. I mean, I
don't what to have put several IFs on the method that updates the resource,
checking several attributes to see if I have a state transition. This
doesn't please me. I'd like to model these Resource Transformations with
finite state machines. I'd like to design this by mapping the states of each
resource and the possible state transitions.
My major was on Eletronic and Computer Engineering, so I learned well how to
apply state machines to eletronic systems. I'm now trying to learn how to
apply finite state machines to software development, and more specifically
to RESTFul web services :)
I'm trying to find time to read this book and get some ideas:
http://www.amazon.com/Modeling-Software-Finite-State-Machines/dp/0849380863/ref=sr_1_1?ie=UTF8&s=books&qid=1206935628&sr=1-1
If you guys find this idea interesting, I'd love to see more discussions on
the subject.
--
Regards,
Bruno Luiz Pereira da Silva
blpsilva_at_gmail.com
http://brunopereira.com.br
On Wed, May 14, 2008 at 7:57 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> Bruno Luiz Pereira da Silva wrote:
>
> > What we did was identifying a new Order resource. This resource was not
> > one of the business objects. We didn't have an Order class in our domain
> > model. But using this new Resource made everything much clearer. The
> > operation become the creation of a new Order resouce. The Order resource
> > contains the products and the billing data.
> >
> >
> It is nice to read this :-) this is often a blocking point when in the
> design process. The solution can appear rather simple afterwards but it is
> not always obvious how to get to it. It is really easy to "mint" new URIs,
> create URIs for all important information you need to expose.
>
> For example, a developer a JavaOne asked me how could one set the state on
> multiple printers all at once (e.g. disable) rather than performing multiple
> requests to all printers. One could have a resource for a set of printers
> that represents the current aggregated state. One could PUT to this URI to
> update the state for all printers. Another solution is to POST to a general
> printers resource with the set of printers+state one wants to change, but it
> makes it harder to GET the aggregated state.
>
>
> Paul.
>
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>