The Rails request-response cycle

Direct Answer

A Rack-compatible server passes an HTTP request through the Rails middleware stack, the router matches method and path to a controller action, callbacks and the action run application logic, and Rails builds a status, headers, and body that travels back through middleware to the server and client.

Deep Dive & Architecture

The application server accepts a network request and passes a Rack environment hash to Rails. That environment contains request method, path, headers, input, server information, and shared objects added by earlier middleware. Rails wraps it with request helpers, but the underlying contract remains a callable application returning [status, headers, body].

Middleware forms a nested chain. A request ID layer may add an identifier before dispatch and copy it to response headers afterward. Session middleware can decode a session cookie before a controller reads session. Exception middleware can catch an error raised deeper in the stack and turn it into an environment-appropriate response. bin/rails middleware reveals the real configured order, which differs between full and API-only applications.

Routing considers both method and path. GET /articles/42 and DELETE /articles/42 can reach different actions even though the path text is identical. Dynamic segments become parameters. The dispatcher instantiates the controller, runs applicable callbacks, and invokes the public action. Authentication and authorization should happen before protected business work, while parameter filtering protects mass assignment at the controller boundary.

The action coordinates rather than doing every job itself. It may load Active Record relations, invoke domain or service code, enqueue a background job, then render JSON or return an empty response. Rendering constructs the body for the current request; redirecting instead sends a 3xx response whose Location invites the client to make a later request.

On the outward path, middleware can compress the body, add headers, finalize logs, or handle exceptions. The server writes the HTTP response to the client. Observability should follow the same journey: correlate request ID, route, controller action, database queries, job enqueueing, status, and duration. This map turns a vague 'Rails is slow' report into a specific middleware, query, serialization, or network question.

A minimal diagnostic starts with the route table, then middleware order, controller logs, query trace, and final response. Checking in that sequence follows the same path as the request and prevents a database investigation when the router never dispatched the action.

Code Example

class Api::ArticlesController < ActionController::API
  before_action :authenticate_token!

  def show
    article = Article.find(params[:id])
    response.set_header("X-Request-ID", request.request_id)
    render json: { id: article.id, title: article.title }
  end

  private

  def authenticate_token!
    head :unauthorized unless request.authorization.present?
  end
end

The callback runs before the action, route parameters identify the record, and the renderer creates the current response.

Common Mistakes & Pitfalls

Saying the request goes directly to a model or that render sends a second browser request.