Controllers & Actions

In Ruby on Rails the controller is the coordinator: each public method, called an action, receives a request, works with models, and decides what to send back. It's the C in MVC.

Learn Controllers & Actions in our free Ruby course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick reference.

Part of the free Ruby course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

By the end of this lesson you'll write the standard CRUD actions, read the params hash, choose between render and redirect_to, and share setup with before_action.

What You'll Learn in This Lesson

1️⃣ Actions, params, render and redirect

Each action is a method on the controller. It reads input from params , talks to a model, and then either render s a view or redirect_to s another URL.

The remaining actions complete CRUD. Notice the private post_params method — strong parameters whitelist the fields you accept.

2️⃣ Sharing Setup with before_action

Several actions need the same record. A before_action runs a method before chosen actions, so you load @post once instead of repeating the lookup.

Your turn. Complete the index and show actions for articles.

For each HTTP request, name the controller action that handles it.

📋 Quick Reference — Controllers

Practice quiz

Which controller action conventionally LISTS all records?

  • show
  • index
  • create
  • edit

Answer: index. The index action lists all records of a resource.

How does a controller read submitted form and URL data?

  • Through the params hash
  • Through the @request variable
  • Through cookies only
  • Through the routes file

Answer: Through the params hash. Incoming data (query string, form fields, path segments) is available in the params hash.

After a successful create, what should the controller usually do?

  • render :new again
  • redirect_to the new record (or its index)
  • raise an error
  • call params.save

Answer: redirect_to the new record (or its index). On success you typically redirect_to the record, following the POST-redirect-GET pattern.

What is the purpose of before_action?

  • It deletes the database
  • It runs shared setup code before chosen actions
  • It defines the routes
  • It renders the layout

Answer: It runs shared setup code before chosen actions. before_action runs a method before specified actions, ideal for shared setup like loading a record.

Which action handles the DELETE request to remove a record?

  • remove
  • delete
  • destroy
  • drop

Answer: destroy. The destroy action handles deletion of a record.

What does render :new do inside an action?

  • Redirects the browser to /new
  • Renders the new view template without a new request
  • Creates a database record
  • Defines a route

Answer: Renders the new view template without a new request. render :new displays the new template directly, keeping the current request (and any errors).

The difference between render and redirect_to is:

  • They are identical
  • render runs a migration; redirect_to deletes data
  • render shows a view in the same request; redirect_to tells the browser to make a new request
  • redirect_to is only for JSON

Answer: render shows a view in the same request; redirect_to tells the browser to make a new request. render produces a response now; redirect_to sends the browser to a new URL, triggering a fresh request.

In show, how do you find the record from the URL /posts/5?

  • Post.all
  • Post.new

Post.find(params[:id]) looks up the record whose id matches the :id from the path.

Which pair of actions render forms rather than change data?

  • new and edit
  • create and update
  • index and destroy
  • show and create

Answer: new and edit. new and edit render forms; create and update are the actions those forms submit to.

Why use strong parameters like params.require(:post).permit(:title)?

  • To speed up the server
  • To allow only approved fields, preventing mass-assignment of unexpected data
  • To define routes
  • To render a partial

Answer: To allow only approved fields, preventing mass-assignment of unexpected data. Strong parameters whitelist permitted fields, protecting against unwanted mass assignment.