Colin Law wrote in post #1109974: > There is no need for a separate controller, one way would be to handle > it within the flights controller Edit action, using a url parameter or > the Submit button name to indicate that cancel is required rather than > edit. > However, REST should not be treated as a religion to which all > requirements must bow. I would say there is nothing wrong with what > you have done (provided that you have used a POST to do it).
Don't you mean PATCH/PUT rather than POST? POST would indicate you are creating a new flight on the collection of flights, rather than changing the state of an existing flight. Sure POST would work (and technically PATH/PUT is simulated using a POST), but using PATCH/PUT would be more conventional in a RESTful application. I agree it seems to be overkill in this case to create a separate controller. I see nothing wrong with adding a "cancel" method to the flight controller. Having additional methods in a controller isn't un-RESTful IMHO. You have a URL (http://example.com/flights/1/cancel) that represents a change (PATCH/PUT) to an existing resource. What's un-RESTful about that? http://guides.rubyonrails.org/routing.html#adding-more-restful-actions If I were designing a system like this I would most likely implement my "Flight" model as a finite-state machine and use additional controller actions (along with the 7 default ones) to transition the flights through their various states. https://en.wikipedia.org/wiki/Finite-state_machine -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/0e3f1abdf810fc4512863ba205d5b8dd%40ruby-forum.com?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
