I have an apartment search app that has a Listings model. It has the typical controller actions like create, new, index, update, but a listing can also be canceled, resumed (after being cancelled), renewed, and shared on facebook. Currently, they’re all in the Listing. Any suggestions and advice on organizing non-restful controller actions would be appreciated.
I would say that “cancellation” fits nicely in a destroy action that ‘soft deletes’ your Listing.
Resume, Renew, and Share are all conceptual resources and can be implemented in their own controllers:
resumptions#new => undelete a listing
shares#new => share to facebook (this can also just be a link to facebook with the appropriate link)
1 Like
Ok cool. Are there circumstances where it is acceptable to be non-restful?
Also, I’m guessing if I allow both permanent and soft deletes, then I’d have a separate controller for cancellations as well?
Thanks!
Restful is just one way of designing an http API. If you find a case that REALLY doesn’t seem like a good fit, don’t use it. DHH isn’t going to drive to your house to yell at you.
That said, it’s a pretty darn good way to handle a whole bunch of situations. I think your default approach should be to assume that something can probably be restful with a little thought, but then to not use it if it’s not a good fit.
Examining why I’m having a hard time modeling something in a RESTful manner usually helps me tease out a another object or two and simplify existing classes.
I like RESTful API’s but I like what thinking in REST does for my OO design more.