Rails Controllers
Fast recall
Quick revision
Core answer
Whether you know a controller receives params, talks to models, and renders; that actions are methods; and that controllers should be thin (no business logic).
Putting business logic in controllers (they should delegate to models/services), or forgetting strong params (mass-assignment risk).
A controller receives params, asks models for data, and renders. Actions are methods. Controllers are thin: find, authorize, delegate, render. Strong params guard mass-assignment.
Interview-ready guide
Interview answer
A Rails controller receives the request after routing and coordinates its application use case. An action is a public method such as create or show; it can read params, session or authentication context, call domain code, and select the HTTP response.
For example, ProductsController#create can build a Product from permitted attributes, call save, redirect to the product after success, and render the form with validation errors after failure. The controller owns that HTTP decision, while the Product owns its validation rules.
Strong parameters are part of this boundary. params.expect(product: [:name, :price]) in current Rails, or require(...).permit(...) in many existing applications, prevents arbitrary request keys from being mass-assigned. Authentication and shared setup may run through carefully scoped action callbacks.
An action should produce one response. It should not contain long SQL chains, pricing algorithms, email templates, or unrelated orchestration. Those details become easier to reuse and test when delegated to a model, query object, or service with a clear contract.
A good controller therefore translates HTTP input into an application call and translates the result back into HTTP without becoming the application itself.
Rails Controllers
Direct Answer
A Rails controller is the HTTP-facing coordinator for a request. The router selects a public action; the controller reads request context and permitted parameters, invokes models or application services, and chooses a response by rendering, redirecting, or returning a status. It should not become the permanent home for domain rules, complex queries, or presentation markup. A focused controller makes the request contract clear while delegating reusable work.
Deep Dive & Architecture
Rails constructs a controller instance for the request and runs the selected action through the controller callback chain. Filters may establish authentication or load shared resources, but their order and scope affect every matching action and should remain visible enough to reason about.
Parameters combine values from routing, query strings, and request bodies. Treating that hash as trusted would let a client set fields it should not control. A permitted-attribute boundary creates an explicit input shape before data reaches mass assignment, while deeper domain validation still decides whether values are acceptable.
The result must become one HTTP response: body, status, and headers. Rendering a failed form normally keeps the same request and uses a failure status such as 422. Redirecting after a successful write asks the client to make a clean GET, preventing a refresh from resubmitting the mutation.
Thin does not mean empty. Request-specific branching, content negotiation, and status selection belong here. The design smell is logic whose meaning and tests do not depend on HTTP; moving that logic behind a named method leaves the controller as a readable map of the endpoint.
Code Example
class ProductsController < ApplicationController
def create
@product = Product.new(product_params)
if @product.save
redirect_to @product, status: :see_other
else
render :new, status: :unprocessable_entity
end
end
private
def product_params
params.require(:product).permit(:name, :price)
end
end
Common Mistakes & Pitfalls
Putting business logic in controllers (they should delegate to models/services), or forgetting strong params (mass-assignment risk).
Check your understanding
Answer these without looking back at the article.
- Why are strong parameters separate from model validations?
- What kinds of logic should move out of a controller?
- When is a `before_action` helpful, and when can it hide control flow?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.