Как устроен цикл обработки запроса в Ruby on Rails?

Обычный HTTP-запрос к Rails проходит несколько уровней. Не каждый из них обязан выполнять работу: кеширующий middleware, например, может вернуть ответ раньше контроллера.

1. Сервер приложения, например Puma, принимает запрос. Перед ним может стоять Nginx, но это не обязательная часть Rails.
2. Rack задаёт интерфейс вызова приложения: сервер передаёт окружение запроса, приложение возвращает статус, заголовки и тело. Rack — интерфейс и инфраструктура, а не отдельный сетевой сервер между Puma и Rails.
3. Middleware оборачивают обработку: ведут журнал, обслуживают сессии, обрабатывают ошибки и выполняют другие задачи. Состав зависит от конфигурации.
4. Router сопоставляет HTTP-метод и путь с маршрутом, выбирая action контроллера.
5. Контроллер получает параметры, выполняет callbacks, вызывает модели или прикладные сервисы и формирует ответ.
6. Представление нужно, если ответ собирается из шаблона. Для render json: HTML-шаблон не обязателен.
7. Ответ проходит обратно через обёртки middleware и отправляется клиенту сервером. Rails и Rack

Минимальный прикладной пример при существующей модели Product:

# config/routes.rb
get '/products/:id', to: 'products#show'

# app/controllers/products_controller.rb
class ProductsController < ApplicationController
  def show
    product = Product.find(params[:id])
    render json: { id: product.id, name: product.name }
  end
end

Запрос GET /products/42 попадёт в show. При успехе получится JSON-ответ; если записи нет, возникнет ActiveRecord::RecordNotFound, далее работает настроенная обработка ошибок.

Модель не обязана участвовать в каждом запросе, а всю бизнес-логику не следует механически помещать в контроллер. Его роль — координировать обработку HTTP-взаимодействия. Обзор Action Controller