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.