# REST best practices for customized views **URL:** \ **Category:** Rails\ **Created:** [February 11, 2008, 1:55am UTC](https://www.ruby-forum.com/t/rest-best-practices-for-customized-views/128724 "2008-02-11T01:55:43Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Thaddeus\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/43a26b/32.png) [@Thaddeus\_S](https://www.ruby-forum.com/u/Thaddeus_S)\ **Post date:** [February 11, 2008, 1:55am UTC](https://www.ruby-forum.com/t/rest-best-practices-for-customized-views/128724/1 "2008-02-11T01:55:43Z")
I’m looking for some advice on REST best practices for providing two different views that update the same resource. I’m working on a hotel registration system and there are two different views that edit the guest model. The first one is used to take/update reservations and enter all the basic guest information. The second one is used to check-in guest by providing a quick update from a list of search results. The clerk can enter room number, etc in the table and update the guest right there; it then takes the guest back to the search page. The problem is that both of these should do a PUT on the guest to update the information. My question is where should those two actions reside, and how should I handle two different redirections from the update action? I’ve thought about creating another model called registration that the second case updates, but that seems a little overkill. What about a second controller and routes with name\_prefix? Are there best practices for this situation? Any thoughts or recommendations would be appreciated. ## ~Thadd Thadd Selden removed\_email\_address@domain.invalid [http://www.thaddeus.net](http://www.thaddeus.net) ```auto "Gentlemen, bring me that horizon." ``` ---
**Author:** ![Thaddeus\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/43a26b/32.png) [@Thaddeus\_S](https://www.ruby-forum.com/u/Thaddeus_S)\ **Post date:** [February 11, 2008, 2:16am UTC](https://www.ruby-forum.com/t/rest-best-practices-for-customized-views/128724/2 "2008-02-11T02:16:13Z")
On 2/10/08, Thaddeus S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > it then takes the guest back to the search page. > Are there best practices for this situation? Any thoughts or > recommendations would be appreciated. It seems to me that there should be three different resources here: Guest Reservation - created when the guest makes a reservation RoomAssignment -created when the guest checks in. I don’t think that making/changing a reservation, or checking in or out should change the guest. – Rick DeNatale My blog on Ruby [http://talklikeaduck.denhaven2.com/](http://talklikeaduck.denhaven2.com/) ---
**Author:** ![Thaddeus\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/43a26b/32.png) [@Thaddeus\_S](https://www.ruby-forum.com/u/Thaddeus_S)\ **Post date:** [February 11, 2008, 9:33pm UTC](https://www.ruby-forum.com/t/rest-best-practices-for-customized-views/128724/3 "2008-02-11T21:33:56Z")
I agree with Rick, but the problem itself is interesting, how to handle a situation where you have more than one action for one resource - I used this solution: map.resources :events, :member =\> {:show2 =\> :get} because I had two completely different actions (show and show2 in events\_controller) for one event. Any other solution would be appreciated… Philipp ---
**Author:** ![Thaddeus\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/43a26b/32.png) [@Thaddeus\_S](https://www.ruby-forum.com/u/Thaddeus_S)\ **Post date:** [February 12, 2008, 8:03pm UTC](https://www.ruby-forum.com/t/rest-best-practices-for-customized-views/128724/4 "2008-02-12T20:03:53Z")
I think that you need to sharpen your use cases to clarify the object each user has for the view. The second screen is described as being used by both a clerk and a user/guest. This may have been a casual mistake but it sounds like you’re not clear on the specifics… getting that clarity will help. From what is posted, it sounds like the goal of the first view is to create or update a Reservation. It sounds very much like the view should be focused on the reservation and any guest fields would be handled through the Reservation. That is, you’d put/post to the ReservationsController and have something like this… def update @reservation = Reservation.find(params[:id]) if @reservation.update\_attributes(params[:reservation]) && @reservation.guest.update\_attributes(params[:guest]) … end The second screen really sounds like it’s no different. A clerk looks up ‘Today’s Reservations’ and finds Mr. Smith’s reservation in the index. He keys the room assignment, Mr. Smith’s local contact number, etc into the grid and click’s the ‘Assign Room’ button on the row. But ‘assign room’ is really just updating the Reservation through the ReservationsController. There is no need to use the Guest controller at all. From the UI perspective the Reservation resource includes a ‘guest’ attribute for which it proxies updates.