rails-controllers

RESTful Rails controllers map CRUD actions to standard HTTP methods (GET, POST, PUT, DELETE) on resources. Use Rails resourceful routing to automatically generate seven standard actions—index, show, new, create, edit, update, destroy—that correspond to REST principles, keeping each action focused on a single responsibility.

Thin controllers delegate complex behavior to domain models and service objects. Move business logic, validations, and data transformations out of controller actions into model methods, so controllers only handle HTTP concerns: routing, parameter extraction, authorization checks, and response formatting.

Centralize authorization and error responses using before_action filters and rescue_from blocks. Define authorization logic in a shared concern or base controller, and standardize error responses—returning appropriate HTTP status codes and JSON payloads—so all endpoints behave consistently.

Prefer nested resources and standard REST actions over custom actions. Nested controllers—like /posts/:post_id/comments—map domain relationships to URL structure naturally. Custom actions (like /posts/:id/publish) obscure intent; use POST to a resource or a state-transition pattern instead.

Validate parameters in model layers using Rails validations or form objects, then check results in the controller. For idempotent endpoints (PUT, PATCH), design updates to succeed safely when repeated; use conditional requests (ETags) and ensure side effects occur only on state change.

Yes. RESTful controller patterns work for both JSON APIs and HTML rendering. Use respond_to or content negotiation to serve different formats from the same action, keeping controller logic identical—only the view or serializer layer changes based on requested media type.