REST and context

hi all. I'm developing my latest rails app using a REST style. I've
hit a bit of a problem with context however. Let's say I have an Item
model. I'm using edit/update to handle the processing, but the model
is edited differently depending on the context.

sometimes all I'm doing is changing a 'status' attribute and don't
need to show the entire form. In other cases I could be editing
associated objects along with the main objects, and then there are
user permissions to consider. Some user can edit some of the
attributes and others can't. Even confirmation messages stored in
flash after a successful update vary.

All these operations are essentially an edit/update but the different
contexts make it more complicated. For now I'm using separate actions
for each type of update so for example, changing the status is handled
by /items/mark_as_sold. Another way I could do this is to have a url
parameter in the call to edit or update and process the request
differently depending on the context but this gets messy.

How do other developers handle these situations? Is there a 'rails
way' to do it?

thanks ev

Evan C wrote:

hi all. I'm developing my latest rails app using a REST style. I've
hit a bit of a problem with context however. Let's say I have an Item
model. I'm using edit/update to handle the processing, but the model
is edited differently depending on the context.

sometimes all I'm doing is changing a 'status' attribute and don't
need to show the entire form. In other cases I could be editing
associated objects along with the main objects, and then there are
user permissions to consider. Some user can edit some of the
attributes and others can't. Even confirmation messages stored in
flash after a successful update vary.

- The application API should have nothing to do with your views.
- Associated objects should be edited though their own API.
- User permissions (authorization) are typically handled by the
controller layer, and should typically apply to the API the same as for
your web views.
- Messages for the API are independent of any Flash messages presented
to the users of web forms. Errors for the API follow the HTTP standard
error codes (Example: format.xml { render :@posts.errors, :status =>
:unprocessable_entity }.

All these operations are essentially an edit/update but the different
contexts make it more complicated. For now I'm using separate actions
for each type of update so for example, changing the status is handled
by /items/mark_as_sold. Another way I could do this is to have a url
parameter in the call to edit or update and process the request
differently depending on the context but this gets messy.

Adding additional action methods for things like "mark_as_sold" sound to
me more like a Remote Procedure Call (RPC) style API. This should not be
necessary. Either the user is authorized to update the field or he
isn't. In either case the basic RESTful update action should be all that
is necessary. As I mentioned before, the view layer should have no
affect on your controller layer API. If you have a form that allows only
changing the status field that's fine. There should be no reason it
can't share the same "update" controller action.

How do other developers handle these situations? Is there a 'rails
way' to do it?

I don't know that it's necessarily a Rails specific way to do it, but
there is certainly an MVC way, which is the core purpose of MVC to begin
with.