Extract from the http://guides.rubyonrails.org/routing.html#singular-resources documentation:
Because you might want to use the same controller for a singular route (/account) and a plural route (/accounts/45), singular resources map to plural controllers. So that, for example, resource :photo and resources :photos creates both singular and plural routes that map to the same controller (PhotosController).
Instead of “Because you might want”, I would argue YAGNI on this one. When there is a singular REST resource, I often do this kind of code in my routes.rb file:
Example 1: current logged-in user
resource :user, only: [:show, :update], controller: :user
Example 2: single sub-resource
namespace :user do
resource :basic_information, only: :show, controller: :basic_information
Example 3: there is only one dashboard when you are logged-in
resource :dashboard, only: :show, controller: :dashboard
This way, I have singular controller names for my singular resources. In example 3, a DashboardsController name does not make sense when you are logged-in. DashboardController feels more natural. If I ever need to have multiple dashboards in the future, I would remove controller: dashboard, but meanwhile, YAGNI (and in this case, this will probably never happen).
Repeating the name twice in the resource declaration feels a bit hacky, that is why I would like to modify Rails so that it has built-in single controller handling.
I have two solutions in mind:
- The “quick fix” solution: being able to add singular: true to any resource. Does not introduce any regressions in existing Rails apps. Example:
resource :user, only: :show, singular: true
- The “deep fix” solution: have resource map to a singular controller by default. This would break most existing Rails apps, they would need to migrate. But I feel like this is the best one. Example:
What do you guys think? If this seems sensible, I would like to make a PR for that.