Rails - Dec 2006 - RESTful CRUD-Controllers by simulating trivial resource

Hi,

I would like to know your opinion on the following idea:

In order to keep controllers normalized you often have to introdruce
new models whose CRUD-actions replace non-CRUD-actions. But sometimes
the resulting resources can be nearly trivial. Example: User
activation.

=== RPC approach ==
user_controller.rb:

def activate
  @user = User.find_by_activiation_ticket(params[:activation_ticket])
  @user.update_attributes(:activated => true)
end

You *could* refactor this to REST like so:

=== REST approach by introducing new resource ==
- Create model UserActiviation:

user_activation.rb:

class UserActivation < AR
  belongs_to :user
end

- Create CRUD-Controller UserActivationController.

Downsides:
- Database overhead to find out if a user is activated
- Seems to be a bit overkill, if you ask me.

Therefor:

=== REST approach by simulating the existance of a resource ==
- *Only* create a UserActivationController

user_activation_controller.rb:

class UserActiviationController < AppController
  def create
    if params[:user_activation][:user_id]
      @user = User.find(params[:user_activiation][:user_id])
      @user.update_attributes(:activated => true)
    end
  end
end

That way your api is stricty RESTful. But you do not have to pay the
cost of introducing nearly trivial models.

What do you think?


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi,

REST doesn''t imply having to model *everything* to CRUD, hence  
support for member functions.
An example from my routes ...

  map.resources :subscriptions, :path_prefix => '':locale/ 
admin'', :controller => ''admin/subscriptions'',
:name_prefix =>
''admin_'', :member => { :upgrade => :put, :downgrade
=> :put} do |
subscription|
    subscription.resources :payments, :controller => ''admin/ 
payments'', :name_prefix => ''admin_''
end

You could implement yours like this ...

Class UsersController.rb < AC::Base

   #CRUD actions here

   def activate
     @user = User.find_by_activiation_ticket(params[:activation_ticket])
     @user.update_attributes(:activated => true)
   end

end

your route:

map.resources :users, :member => { :activate => :put } #post / get if  
u like

and invoked with users/1;activate

see http://blog.methodmissing.com/2006/10/30/restful-routes-and- 
namespaced-controllers , anything''s possible with REST and routes,  
without having to add additional overhead.

- Lourens

   http://blog.methodmissing.com

On 2006/12/12, at 20:05, timfischbach wrote:
>
> Hi,
>
> I would like to know your opinion on the following idea:
>
> In order to keep controllers normalized you often have to introdruce
> new models whose CRUD-actions replace non-CRUD-actions. But sometimes
> the resulting resources can be nearly trivial. Example: User
> activation.
>
> === RPC approach ==>
> user_controller.rb:
>
> def activate
>   @user = User.find_by_activiation_ticket(params[:activation_ticket])
>   @user.update_attributes(:activated => true)
> end
>
> You *could* refactor this to REST like so:
>
> === REST approach by introducing new resource ==>
> - Create model UserActiviation:
>
> user_activation.rb:
>
> class UserActivation < AR
>   belongs_to :user
> end
>
> - Create CRUD-Controller UserActivationController.
>
> Downsides:
> - Database overhead to find out if a user is activated
> - Seems to be a bit overkill, if you ask me.
>
> Therefor:
>
> === REST approach by simulating the existance of a resource ==>
> - *Only* create a UserActivationController
>
> user_activation_controller.rb:
>
> class UserActiviationController < AppController
>   def create
>     if params[:user_activation][:user_id]
>       @user = User.find(params[:user_activiation][:user_id])
>       @user.update_attributes(:activated => true)
>     end
>   end
> end
>
> That way your api is stricty RESTful. But you do not have to pay the
> cost of introducing nearly trivial models.
>
> What do you think?
>
>
> 
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi,

thanks for your answer. You''re right: The original approach does not
necessarily conflict with REST and resource orientated routing.

But I still think that there are situations where you might want to
provide a strict CRUD-interface for your controllers. For example to
allow easy integration with ActiveResource (which does not really allow
invocation of actions identified by an ";ascept"-syntax, right?).

Maybe my example was a bit weak, since user activation will not often
have to be invoked by webservices. The main idea of my original post
was the following: Since REST is all about representations there is no
absolute need to introduce a model for every controller. If these
"virtual" resources are accessible like all the others from outside,
the internal way of storing them does not matter.

And this might be an interesting thing to consider, since some of
REST''s downsides that I see relate to database issues.

Tim


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---