Re: [Rails] How to do it the rest way ? Question from fledgeling Ruby programmer

[Colin Law]

On 23 May 2013 12:56, Mateusz Urban <mateus...@gmail.com> wrote:
> Hi!
> Reading "Rails For .NET Developers" i started to consider the example of
> building the flight system with cancellations. So, I've generated flights
> scaffold and passengers scaffold and I'd like that we could cancel the
> flight and then, each of the passengers would be informed about that fact.
> So, firstly i've written a non-rest code and simply added "cancel_flight"
> method to my FlightsController and generated required routes in routes.rb.
> And it looks like this:
>>>
>>> def cancel_flight
>>>
>>> flight = Flight.find(params[:flight])
>>>
>>>
>>>
>>> flight.cancel_flight
>>>
>>>
>>>
>>> redirect_to flights_path
>>>
>>>
>>>
>>> end
>
> (where Flight model has a method cancel_flight, which of course knows what
> to do)

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).

Colin

[Robert Walker]

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/.

[Colin Law]

On 23 May 2013 21:30, Robert Walker <li...@ruby-forum.com> wrote:
> 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.

Yes, I was speaking loosely (which is a cardinal sin) and using POST
to mean one of the set of non-GET verbs. I am showing my age, going
back to the days when there were only the two options.

Colin

>
> 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 rubyonrails-ta...@googlegroups.com.
> To post to this group, send email to rubyonra...@googlegroups.com.
> 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.
>
>

[Robert Walker]

Colin Law wrote in post #1109983:

> On 23 May 2013 21:30, Robert Walker <li...@ruby-forum.com> wrote:
>> 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.
>
> Yes, I was speaking loosely (which is a cardinal sin) and using POST
> to mean one of the set of non-GET verbs. I am showing my age, going
> back to the days when there were only the two options.
>
> Colin

Well technically there are still only two options from inside a web
browser. Still can't fathom why that hasn't been fixed in modern
browsers. :)