この記事では、Rails API の Controller とは何か、 そして Controller がどのような役割を担い、どこまで処理を書いてよいのかを、基本から順を追って解説します。
Rails API を学習していると、
- Controller が何を担当する場所なのか分からな
- なんとなく Controller に処理を書いてしまっている
- Controller が何を担当する場所なのか分からない
- なんとなく Controller に処理を書いてしまっている
といった悩みに直面しがちです。
これらを解消するために、この記事を通して、 Rails API における Controller の役割を整理しながら学んでいきましょう。
1. Railsのルーティングとは何か?
Controller とは、 HTTP リクエストが送られてきたときに、routes.rb の定義に従って呼び出される処理(メソッド)を書いておく場所です。
Rails API では、Controller の中でパラメータを参照し、処理結果を JSON などのレスポンスとして返します。
以降の章で、この Controller がどのような役割を担い、 どこまで処理を書いてよいのかを、具体例とともに見ていきます。
2. Rails APIにおけるControllerの位置づけ
Rails API における、 リクエスト処理の基本的な流れ は次のとおりです。
HTTPリクエスト
↓
ルーティング
↓
コントローラ(Controller)
↓
レスポンス(JSON)
クライアントからリクエストが送られてくると、
- routes.rb に定義されたルーティングをもとに
- 処理を担当する Controller とアクションが決まり
- Controller が呼び出され
- 処理結果をもとに、JSON などのレスポンスが返される
Controller は、 ルーティングによって呼び出され、 処理結果をレスポンスとして返す役割 を担います。
※ どの URL がどの コントローラ/アクション に対応するかは、routes.rb に定義されたルーティングによって決まります。ルーティングの詳しい仕組みについては、「Railsのルーティングとは|routes.rbとresourcesの基本をRails APIでわかりやすく解説」の記事で解説しています。
3. Controllerの基本的な書き方
ここでは、最もシンプルな Controller の例を見てみましょう。
class UsersController < ApplicationController
def show
user = User.find(params[:id])
render json: user
end
end
このコードでは、
UsersController→ users に関するリクエスト・処理を扱う Controller クラス。show→ ユーザー詳細に関する処理を行うメソッド(アクション)。params[:id]→ URL から渡されたパラメータ(ここでは id を取得)。render json:→ JSON 形式でレスポンスを返す(ここでは user を返す)。
という役割を持っています。
4. Rails APIでよく使うControllerの処理例
次に、Rails API でよく使われる Controller の処理例を見てみます。
def create
user = User.new(user_params)
if user.save
# userがDBに保存できた場合のレスポンス(「:created」のステータスコードは「201」)
render json: user, status: :created
else
# userがDBに保存できなかった場合のレスポンス(「:unprocessable_entity」のステータスコードは「422」)
render json: { errors: user.errors }, status: :unprocessable_entity
end
end
この処理では、
- パラメータ(user_params)を参照する
- データの作成処理を Model に任せる(User.new / user.save)
- 成功・失敗に応じてレスポンスを返す(user.saveの処理結果に応じてレスポンスを切り替え)
といったことを行っています。
このように、
- HTTP ステータスコードを返す
- レスポンスの形式を整える
といった処理は、Controller の重要な役割です。
5. Controllerに書いてよいこと・書かない方がよいこと
ここまでを踏まえて、Controller に書いてよいこと・書かない方がよいことを整理します。
5-1. Controllerに書いてよいこと
- パラメータの参照・整理
- 処理の呼び出し
- レスポンスの整形(JSON / ステータスコード)
5-2. Controllerに書かない方がよいこと
- 複雑なビジネスロジック
- 条件分岐が多い判断処理
以下のような場合は、Controller の責務を超え始めています。
- 業務ルール(「ビジネスとしてどう振る舞うか」という決まりごと)が増えている
- 将来的に条件が増えそうな処理を書いている
こうした処理は、Model や Service クラスに切り出すことで、 Controller をシンプルに保つことができます。
※ どのようにロジックを切り出すか、なぜそれが設計として望ましいのかについては、別の記事で詳しく解説します。
おわりに
この記事では、Rails API における Controller の役割を整理しながら、
- Controller とは何か
- リクエスト処理の中でどの位置にあるのか
- どこまで処理を書いてよいのか
を解説しました。
Controller は、処理をすべて書く場所ではなく、 ルーティングによって呼び出され、 処理結果をレスポンスとして返す役割を担う存在です。
この役割を意識するだけで、Controller は読みやすく、保守しやすいコードになります。
本記事が、Rails API における Controller を 「なんとなく書くもの」から「役割を理解して設計できるもの」へ 変えるための一助になれば幸いです。
