第4回：Ruby on Rails実践：CRUD操作とAPI開発

はじめに

Qiita記事シリーズ「5つの記事でバックエンドがわかる！？」の第4回です！

前回は、Ruby on Railsの基本的な概念、MVCモデル、ルーティング、コントローラ、ビュー、そしてActive Recordによるデータベース連携の基礎について、フロントエンドエンジニアの視点から解説しました。Webアプリケーションの「骨格」がどのように作られているか、イメージが掴めてきたのではないでしょうか。

今回は、いよいよRailsを使った具体的なWebアプリケーション開発の実践に入ります。Webアプリケーションの基本である「CRUD操作（Create, Read, Update, Delete）」の実装方法と、フロントエンドとの連携に不可欠な「API開発」に焦点を当てて解説します。さらに、アプリケーションのセキュリティを保つ上で重要な「認証・認可」の基礎についても触れていきます。

これらの知識を習得することで、フロントエンドの皆さんが普段利用しているAPIがバックエンドでどのように実装されているのかを深く理解し、より効率的で安全なWebアプリケーション開発に貢献できるようになるでしょう。

1. モデル、ビュー、コントローラを用いたCRUD操作の実装：データのライフサイクルを理解する

CRUD操作は、Webアプリケーションにおけるデータの基本的な操作です。ユーザーが情報を「作成（Create）」し、「読み込み（Read）」、「更新（Update）」し、「削除（Delete）」する一連の流れを指します。フロントエンドの皆さんがフォームからデータを送信したり、一覧画面でデータを表示したりする裏側で、バックエンドではこのCRUD操作が行われています。

Railsでは、MVCモデルとActive Recordを組み合わせることで、これらの操作を効率的に実装できます。ここでは、例として「タスク管理アプリケーション」を想定し、Taskモデルに対するCRUD操作を実装する手順を見ていきましょう。

準備：Taskモデルの作成

まず、Taskモデルを作成します。タスクにはtitle（文字列）とdescription（テキスト）があるとします。これは、フロントエンドでいうところの「データのスキーマ定義」のようなものです。

rails generate model Task title:string description:text
rails db:migrate

これにより、app/models/task.rbというモデルファイルと、データベースのテーブルを作成するためのマイグレーションファイルが生成され、データベースにテーブルが作成されます。フロントエンドから見ると、このTaskモデルがAPIを通じてやり取りする「リソース」の構造を定義していることになります。

コントローラとビューの生成

次に、Taskモデルに対応するコントローラとビューを生成します。Railsには、CRUD操作に必要なコントローラのアクションとビューファイルを一括で生成するscaffoldコマンドがありますが、ここでは各要素の役割を理解するために手動で作成する手順を追ってみましょう。

rails generate controller Tasks index show new create edit update destroy

これにより、app/controllers/tasks_controller.rbと、各アクションに対応する空のビューファイルがapp/views/tasks/以下に生成されます。これらのアクションが、フロントエンドからのHTTPリクエストを受け付ける「エンドポイント」となります。

ルーティングの設定：APIエンドポイントの設計図

config/routes.rbに、tasksリソースに対するルーティングを設定します。resourcesメソッドを使うと、CRUD操作に必要な7つのルーティング（index, show, new, create, edit, update, destroy）がまとめて定義されます。これは、フロントエンドがどのURLにどのようなHTTPメソッドでリクエストを送れば、どのバックエンドの処理が実行されるかを明確にする「APIの設計図」のようなものです。

# config/routes.rb
Rails.application.routes.draw do
  resources :tasks
end

rails routesコマンドを実行すると、定義されたルーティングを確認できます。例えば、GET /tasksはTasksController#indexに、POST /tasksはTasksController#createに対応するといった具合です。

コントローラの実装：リクエストとレスポンスの橋渡し

app/controllers/tasks_controller.rbに、各アクションの処理を記述します。コントローラは、フロントエンドからのリクエストを受け取り、適切なモデル操作を行い、結果をビューに渡す（あるいは直接JSONで返す）役割を担います。

# app/controllers/tasks_controller.rb
class TasksController < ApplicationController
  before_action :set_task, only: [:show, :edit, :update, :destroy]

  # GET /tasks (タスク一覧表示)
  def index
    @tasks = Task.all # 全てのタスクを取得
  end

  # GET /tasks/1 (特定のタスク表示)
  def show
  end

  # GET /tasks/new (新規タスク作成フォーム表示)
  def new
    @task = Task.new
  end

  # POST /tasks (新規タスク作成)
  def create
    @task = Task.new(task_params)
    if @task.save # データベースに保存
      redirect_to @task, notice: 'Task was successfully created.'
    else
      render :new # バリデーションエラーがあればフォームを再表示
    end
  end

  # GET /tasks/1/edit (タスク編集フォーム表示)
  def edit
  end

  # PATCH/PUT /tasks/1 (タスク更新)
  def update
    if @task.update(task_params) # データベースを更新
      redirect_to @task, notice: 'Task was successfully updated.'
    else
      render :edit # バリデーションエラーがあればフォームを再表示
    end
  end

  # DELETE /tasks/1 (タスク削除)
  def destroy
    @task.destroy # データベースから削除
    redirect_to tasks_url, notice: 'Task was successfully destroyed.'
  end

  private
    # 共通処理：特定のタスクを取得
    def set_task
      @task = Task.find(params[:id])
    end

    # ストロングパラメータ：セキュリティのために許可するパラメータを明示
    def task_params
      params.require(:task).permit(:title, :description)
    end
end

task_paramsメソッドは「ストロングパラメータ」と呼ばれ、フロントエンドから送られてくるデータのうち、どのパラメータをデータベースに保存して良いかを明示的に許可するセキュリティ機能です。これにより、悪意のあるパラメータが勝手に保存されるのを防ぎます。フロントエンドの皆さんがAPIにデータを送る際、バックエンドではこのようなチェックが行われていることを意識すると良いでしょう。

ビューの実装：ユーザーへの情報提示

各アクションに対応するビューファイル（app/views/tasks/index.html.erbなど）に、HTMLとERBテンプレートを記述します。ここではindex.html.erbの例を示します。

<!-- app/views/tasks/index.html.erb -->
<h1>Tasks</h1>

<table>
  <thead>
    <tr>
      <th>Title</th>
      <th>Description</th>
      <th colspan="3"></th>
    </tr>
  </thead>

  <tbody>
    <% @tasks.each do |task| %>
      <tr>
        <td><%= task.title %></td>
        <td><%= task.description %></td>
        <td><%= link_to 'Show', task %></td>
        <td><%= link_to 'Edit', edit_task_path(task) %></td>
        <td><%= link_to 'Destroy', task, method: :delete, data: { confirm: 'Are you sure?' } %></td>
      </tr>
    <% end %>
  </tbody>
</table>

  


<%= link_to 'New Task', new_task_path %>

このように、RailsのビューはサーバーサイドでHTMLを生成し、ユーザーに返します。フロントエンドのSPA（Single Page Application）とは異なり、ページ遷移ごとにサーバーから新しいHTMLが送られてくるイメージです。しかし、APIとして利用する場合は、ビューの代わりにJSONなどのデータを返すことになります。

2. RESTful APIの設計と実装：フロントエンドとの効率的な連携

現代のWebアプリケーションでは、フロントエンド（React, Vue.jsなど）とバックエンドがAPIを介して通信する構成が一般的です。Railsは、RESTfulなAPIを効率的に構築するための機能を提供しています。フロントエンドの皆さんが普段fetchやaxiosで叩いているAPIが、バックエンドでどのように作られているのかを見ていきましょう。

RESTful APIとは？：フロントエンド開発者のための基本原則

REST（Representational State Transfer）は、Webサービスの設計原則の一つです。RESTfulなAPIは、以下の原則に従って設計されます。これらの原則を理解することで、APIドキュメントをより深く読み解き、効率的なフロントエンド実装が可能になります。

• リソース: Web上のあらゆるものを「リソース」として扱い、URI（Uniform Resource Identifier）で一意に識別します。例えば、/tasksはタスクの集合、/tasks/1はIDが1の特定のタスクを指します。

• HTTPメソッド: リソースに対する操作（CRUD）をHTTPメソッド（GET, POST, PUT/PATCH, DELETE）で表現します。これはフロントエンドからAPIを叩く際のメソッドと直接対応します。

  • GET /tasks: リソースの取得 (Read) - タスク一覧を取得
  • GET /tasks/1: 特定のリソースの取得 (Read) - IDが1のタスクを取得
  • POST /tasks: リソースの作成 (Create) - 新しいタスクを作成
  • PUT/PATCH /tasks/1: リソースの更新 (Update) - IDが1のタスクを更新
  • DELETE /tasks/1: リソースの削除 (Delete) - IDが1のタスクを削除

• ステートレス: 各リクエストは独立しており、サーバーはクライアントの状態を保持しません。フロントエンドは、各リクエストに必要な情報をすべて含めて送信する必要があります。

• 統一インターフェース: リソースへのアクセス方法が統一されています。これにより、APIの学習コストが下がり、フロントエンド開発者は予測しやすい形でAPIを利用できます。

RailsでのAPI開発：JSONレスポンスの生成

RailsでAPIを開発する場合、通常はconfig/routes.rbでapiスコープを設定し、JSON形式でデータを返すコントローラを作成します。

APIルーティングの設定

# config/routes.rb
Rails.application.routes.draw do
  namespace :api do # /api というパス以下にAPIを配置
    namespace :v1 do # バージョン管理のために /v1 を追加
      resources :tasks, only: [:index, :show, :create, :update, :destroy]
    end
  end
end

namespace :apiとnamespace :v1を使うことで、/api/v1/tasksのようなURLでAPIエンドポイントを管理できます。onlyオプションで、APIとして公開するアクションを限定しています。これにより、フロントエンドは/api/v1/tasksに対してGETリクエストを送ればタスク一覧が、POSTリクエストを送れば新規タスクが作成される、といった具合にAPIを利用できます。

APIコントローラの実装

app/controllers/api/v1/tasks_controller.rbを作成し、JSON形式でデータを返すように実装します。通常のWebページを返すコントローラとは異なり、render json: @tasksのように直接JSONデータを返します。

# app/controllers/api/v1/tasks_controller.rb
module Api
  module V1
    class TasksController < ApplicationController
      # APIコントローラではCSRF対策は不要な場合が多いのでスキップ
      skip_before_action :verify_authenticity_token, only: [:create, :update, :destroy]
      before_action :set_task, only: [:show, :update, :destroy]

      # GET /api/v1/tasks
      def index
        @tasks = Task.all
        render json: @tasks # 全てのタスクをJSON形式で返す
      end

      # GET /api/v1/tasks/1
      def show
        render json: @task # 特定のタスクをJSON形式で返す
      end

      # POST /api/v1/tasks
      def create
        @task = Task.new(task_params)
        if @task.save
          render json: @task, status: :created # 作成成功時は201 Createdを返す
        else
          render json: @task.errors, status: :unprocessable_entity # バリデーションエラー時は422 Unprocessable Entityを返す
        end
      end

      # PATCH/PUT /api/v1/tasks/1
      def update
        if @task.update(task_params)
          render json: @task # 更新成功時は更新されたタスクを返す
        else
          render json: @task.errors, status: :unprocessable_entity
        end
      end

      # DELETE /api/v1/tasks/1
      def destroy
        @task.destroy
        head :no_content # 削除成功時は204 No Contentを返す
      end

      private
        def set_task
          @task = Task.find(params[:id])
        end

        def task_params
          params.require(:task).permit(:title, :description)
        end
    end
  end
end

render json: @tasksのように記述することで、Active Recordオブジェクトが自動的にJSON形式に変換されて返されます。また、status: :createdのようにHTTPステータスコードを指定することも重要です。フロントエンドの皆さんがAPIからのレスポンスを処理する際、これらのステータスコードやJSONの構造を理解していると、エラーハンドリングやデータ表示がスムーズに行えます。

フロントエンドとの連携を意識したAPI開発：より良いAPIのために

フロントエンドエンジニアの視点から見ると、APIは「使いやすさ」が非常に重要です。以下の点を意識してAPIを設計・実装すると、フロントエンド開発が格段に楽になります。

• 明確なドキュメント: APIのURI、HTTPメソッド、リクエストパラメータ、レスポンス形式、エラーコードなどを明確に記述したドキュメントを提供します。Swagger/OpenAPIのようなツールで自動生成できるとさらに良いでしょう。

• 一貫性のあるレスポンス: 成功時もエラー時も、レスポンスの形式を統一することで、フロントエンドでの処理がしやすくなります。例えば、エラーメッセージもJSON形式で返すなどです。

• 適切なHTTPステータスコード: 成功（200 OK, 201 Created）、クライアントエラー（400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 422 Unprocessable Entity）、サーバーエラー（500 Internal Server Error）など、状況に応じた適切なHTTPステータスコードを返します。これにより、フロントエンドはステータスコードを見て適切なエラーハンドリングができます。

• バージョン管理: APIの変更に備え、/api/v1/のようにバージョンをURIに含めることで、後方互換性を保ちやすくなります。これにより、フロントエンドはAPIの変更に柔軟に対応できます。

3. 認証・認可の基礎：安全なWebアプリケーションのために

多くのWebアプリケーションでは、ユーザー認証（ログイン）と認可（アクセス権限の管理）が必要です。Railsでは、DeviseというGemを使うことで、これらの機能を簡単かつ安全に実装できます。フロントエンドの皆さんがユーザーログイン機能や、特定のユーザーにしか表示されないコンテンツを実装する際、バックエンドでどのような仕組みが動いているのかを理解することは非常に重要です。

認証と認可の違い：セキュリティの基本

• 認証 (Authentication): 「あなたは誰ですか？」を検証するプロセスです。ユーザー名とパスワードの組み合わせが正しいかなどを確認し、ユーザーが本人であることを証明します。フロントエンドがログインフォームから送信した情報が、バックエンドで認証されるイメージです。

• 認可 (Authorization): 「あなたは何ができますか？」を検証するプロセスです。認証されたユーザーが、特定のリソースにアクセスしたり、特定のアクションを実行したりする権限を持っているかを確認します。例えば、一般ユーザーは自分の投稿しか編集できないが、管理者は全ての投稿を編集できる、といった権限管理です。

Deviseによる認証の実装：Railsでのログイン機能

Deviseは、Railsアプリケーションに認証機能を追加するためのGemです。ユーザー登録、ログイン、ログアウト、パスワードリセットなど、認証に関する多くの機能を簡単に導入できます。

1. Gemの追加: Gemfileにdeviseを追加し、bundle installを実行します。

   # Gemfile
   gem 'devise'
   

2. Deviseのインストール: 以下のコマンドを実行し、Deviseの設定ファイルを生成します。

   rails generate devise:install
   

3. Userモデルの作成: ユーザー情報を管理するUserモデルをDeviseで生成します。

   rails generate devise User
   rails db:migrate
   

   これにより、Userモデルと、ユーザー認証に必要なカラム（メールアドレス、パスワードのハッシュなど）を持つusersテーブルが作成されます。フロントエンドから見ると、このUserモデルが認証対象のユーザー情報を管理していることになります。

4. ビューのカスタマイズ: Deviseが提供するデフォルトのログイン・登録画面をカスタマイズしたい場合は、以下のコマンドでビューファイルを生成できます。これにより、フロントエンドのUIデザインに合わせて、ログイン画面などを自由に調整できます。

   rails generate devise:views
   

Deviseを導入することで、ログイン、ログアウト、ユーザー登録、パスワードリセットなどの機能が簡単に利用できるようになります。コントローラでは、before_action :authenticate_user!を使うことで、ログイン済みのユーザーのみがアクセスできるページを簡単に設定できます。フロントエンドが特定のページにアクセスする際、バックエンドでこのauthenticate_user!が実行され、ログイン状態がチェックされている、と理解すると良いでしょう。

まとめ

今回は、Qiita記事シリーズ「5つの記事でバックエンドがわかる！？」の第4回として、Ruby on Railsを用いたCRUD操作の実装、RESTful APIの設計と実装、そして認証・認可の基礎について、フロントエンドエンジニアの視点から解説しました。

CRUD操作はWebアプリケーション開発の根幹であり、API開発は現代のフロントエンドとバックエンドを繋ぐ重要な技術です。また、セキュリティの観点から認証・認可の仕組みを理解することは不可欠です。これらの知識を習得することで、フロントエンドの皆さんがAPIをより効果的に利用し、安全で堅牢なWebアプリケーションを構築する力が身についたことでしょう。

次回は、いよいよ最終回です。Ruby on Rails以外の主要なバックエンド言語やフレームワークを紹介し、バックエンド開発のトレンドと今後の学習ロードマップについて解説します。このシリーズで得た知識を活かし、さらに広がるバックエンドの世界を探索していきましょう。お楽しみに！

※最終回はこちら