RESTful updates, redirects and context

Rails
1

Dear group,

Currently I am working on (surprise, surprise) a webshop with a
shopping cart. Now I really like the whole REST thing but I constantly
run into the same problem.
As a user I am browsing the site and add products to the cart. This
results in an UPDATE of the cart object and a redirect_to :back.
However, when I am finalizing an order I tack on some additional info
on the cart object. In this case I want to redirect to the next step
in the ordering process.

But this is just an example, it happens that the update of a resourse
happens in a certain context. The context determines the finalizing
step in the update method(or what ever method). This violates the
stateless principe but I see no way around it. How do you guys handle
this?

With kind regards,
Harm

2

well, somethimes sheer CRUD isn’t enough. but RESTful routes let you
add additional actions for cases like this:

routes

map.espources :carts, :member => {:finalize => :post}

controller

def finalize
#your update code
redirect_to whatever
end

#view
use thhis helper: finalize_cart_path(@cart)

if you see code duplication in the update and finalize action, move it
to a seperate method and call this method from both actions to stay
DRY.

OR: if its really only the redirect, send a hidden field or some other
paremeter to the update action from which you determine weither to
redirect :back or redirect somewhere else.

3

Thank you Thorsten for your reply.
But is that not in conflict with the whole REST principle? I mean,
shouldn’t actions be independant of the context?
I already defined a method called ‘remove_item’ which also updates the
cart but instead of adding an item deletes it. To my mind these two
actions are the same. Both update the cart object but in one case the
params hash is one bigger than the current object and in the other
case one smaller. Again only the redirect differentiates the two. For
example if you think of sending the request as an XML post both the
results would be the same, a 200 header.

Won’t it be better if the context would be entirely kept on the client
side? You could for example sent an Ajax request and do some voodoo
magic in the :on_complete parameter(I’m not that good with JS so I do
not know if you can). For example a redirect_to :some_path in
the :on_success or :on_complete.

But I am getting more and more the feeling that I am not being very
practical here. :slight_smile:

With kind regards,
Harm

4

(another thorsten)
that’s not a perfect world… :wink:

…the site and add products to the cart. This
results in an UPDATE of the cart object and a redirect_to :back…

you could(!) use a create on an order object instead (asuming cart
has_many orders (just one option…)

I already defined a method called ‘remove_item’ which also updates the
cart but instead of adding an item deletes it.

this would in any case be a destroy action, not update.
seems you’re concentrating your thoughts too much on the cart. the thing
has a content and you can apply functionality to them too.

but this kind of problem happens all the time:
take the index
we often have more than one possible index.
list customers
list customers we like
list customers we don’t like
one index action with a param or three index actions
index / index_liked / index_not_liked ?