# REST and context

**URL:** <https://www.ruby-forum.com/t/rest-and-context/180757>\
**Category:** Rails\
**Created:** [December 28, 2009, 5:01pm UTC](https://www.ruby-forum.com/t/rest-and-context/180757 "2009-12-28T17:01:01Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Evan\_C](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/90db22/32.png) [@Evan\_C](https://www.ruby-forum.com/u/Evan_C)\
**Post date:** [December 28, 2009, 5:01pm UTC](https://www.ruby-forum.com/t/rest-and-context/180757/1 "2009-12-28T17:01:01Z")

</div>

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

–

You received this message because you are subscribed to the Google  
Groups “Ruby on Rails: Talk” group.  
To post to this group, send email to removed\_email\_address@domain.invalid.  
To unsubscribe from this group, send email to  
removed\_email\_address@domain.invalid.  
For more options, visit this group at  
[http://groups.google.com/group/rubyonrails-talk?hl=en](http://groups.google.com/group/rubyonrails-talk?hl=en).

---

<div class="post-metadata">

**Author:** ![Evan\_C](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/90db22/32.png) [@Evan\_C](https://www.ruby-forum.com/u/Evan_C)\
**Post date:** [December 28, 2009, 5:40pm UTC](https://www.ruby-forum.com/t/rest-and-context/180757/2 "2009-12-28T17:40:39Z")

</div>

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.