Rails APIモードを使えば、Ruby on RailsでJSON APIを作れます。通常のRailsアプリのようにHTML画面をサーバー側で描画するのではなく、React、Vue、スマホアプリ、外部サービスなどにJSONを返すことを主な役割にします。まずは小さなCRUD APIを作り、通常Railsとの違い、JSONレスポンス、認証やCORSの注意点を順番に押さえるのが近道です。
\nRails公式ガイドでも、API-onlyアプリケーションは rails new my_api --api で作成でき、通常のRailsよりブラウザ向け機能を絞った構成になると説明されています。この記事では、Rails APIモードの概要、通常Railsとの違い、作り方、JSONレスポンスの書き方、実務で注意するポイントまで解説します。
Rails APIモードとは、Railsを画面表示用のWebアプリではなく、JSONを返すAPIサーバーとして使うためのモードです。たとえば、フロントエンドをReactで作り、バックエンドをRailsで作る場合、Rails側はユーザー情報や商品一覧などをJSONで返します。
\n通常のRailsでは、ControllerがHTMLテンプレートを呼び出し、ブラウザにHTMLを返す構成がよく使われます。一方、Rails APIモードではControllerがJSONを返す前提になり、View、helper、assetsなどのブラウザ向け機能は初期状態では省かれます。
\nAPIモードでも、Railsの便利な機能がすべて消えるわけではありません。ルーティング、Controller、Active Record、バリデーション、マイグレーション、ログ、テスト、キャッシュなど、バックエンド開発に必要な機能は引き続き使えます。
\nRails APIモードと通常のRailsアプリの大きな違いは、HTML画面を作るための機能を初期状態で持つかどうかです。Rails APIモードでは、APIサーバーに必要な機能を中心に構成されます。
\n| 比較項目 | \n通常のRailsアプリ | \nRails APIモード | \n
|---|---|---|
| 主な役割 | \nHTML画面を返すWebアプリ | \nJSONを返すAPIサーバー | \n
| Controllerの継承元 | \nActionController::Base | \nActionController::API | \n
| View / helper / assets | \n初期状態で使う | \n初期状態では生成を省く | \n
| Cookie / session / flash | \n画面遷移で使いやすい | \n必要な場合に追加して使う | \n
| 向いている構成 | \nサーバー側で画面も作るWebサービス | \nSPA、スマホアプリ、外部連携API | \n
Rails APIモードは「通常のRailsより必ず優れている」というものではありません。HTML画面をRailsで作るなら通常のRailsアプリが自然です。フロントエンドとバックエンドを分け、RailsをAPIサーバーとして使うならAPIモードが向いています。
\nrails new --apiで新規作成する新しくRails APIアプリを作る場合は、rails new に --api オプションを付けます。これにより、API向けのControllerやgenerator設定でアプリが作成されます。
rails new my_api --api\r\ncd my_apiリソースを作る場合は、通常のRailsと同じようにscaffoldやmodel/controller generatorを使えます。
\nbin/rails g scaffold Article title:string body:text\r\nbin/rails db:migrateAPIモードのscaffoldでは、HTMLテンプレートを作るのではなく、JSONを返すControllerが中心になります。最初はscaffoldで全体像を見てから、自分のAPI設計に合わせてController、serializer、routesを整理すると理解しやすいです。
\nconfig.api_onlyを使う前に影響範囲を見る既存のRailsアプリをAPI中心にしたい場合は、config.api_only = true と ActionController::API の利用を検討します。ただし、既存アプリでView、session、Cookie、flashを使っている場合、単純に切り替えると画面側の機能が壊れる可能性があります。
# config/application.rb\r\nmodule MyApp\r\n class Application < Rails::Application\r\n config.api_only = true\r\n end\r\nend# app/controllers/application_controller.rb\r\nclass ApplicationController < ActionController::API\r\nend既存アプリをAPI化する時は、まず「HTML画面を今後もRailsで返すのか」「JSON APIだけに寄せるのか」を決めましょう。管理画面やログイン画面をRailsで持ち続けるなら、通常RailsのままAPI用Controllerだけを切り出す選択肢もあります。
\nrender json:を明示するRails APIのControllerでは、render json: を使ってJSONレスポンスを返します。APIモードではテンプレートが自動で描画される前提ではないため、各actionで何を返すかを明示することが大切です。
class ArticlesController < ApplicationController\r\n def index\r\n articles = Article.order(created_at: :desc)\r\n render json: articles\r\n end\r\n\r\n def show\r\n article = Article.find(params[:id])\r\n render json: article\r\n end\r\nend作成・更新・削除では、HTTPステータスも一緒に返すと、フロントエンド側が成功・失敗を判断しやすくなります。
\nclass ArticlesController < ApplicationController\r\n def create\r\n article = Article.new(article_params)\r\n\r\n if article.save\r\n render json: article, status: :created\r\n else\r\n render json: { errors: article.errors }, status: :unprocessable_entity\r\n end\r\n end\r\n\r\n def destroy\r\n article = Article.find(params[:id])\r\n article.destroy\r\n head :no_content\r\n end\r\n\r\n private\r\n\r\n def article_params\r\n params.require(:article).permit(:title, :body)\r\n end\r\nend| 処理 | \nよく使うステータス | \n意味 | \n
|---|---|---|
| 一覧・詳細取得 | \n200 OK | \n正常にデータを返す | \n
| 作成成功 | \n201 Created | \n新しいリソースを作成した | \n
| 削除成功 | \n204 No Content | \n本文なしで成功を返す | \n
| 入力エラー | \n422 Unprocessable Entity | \nバリデーションエラーなど | \n
| 認証エラー | \n401 Unauthorized | \nログインやtokenが必要 | \n
Rails APIでも、RESTfulなルーティングとStrong Parametersを使って入力値を安全に扱います。APIだからといって、受け取ったJSONをそのままModelへ渡すのは避けましょう。
\n# config/routes.rb\r\nRails.application.routes.draw do\r\n resources :articles, only: %i[index show create update destroy]\r\nendparamsで受け取るフロントエンドから次のようなJSONを送る場合、Rails側では params から値を取得できます。
{\r\n \"article\": {\r\n \"title\": \"Rails API入門\",\r\n \"body\": \"RailsでJSON APIを作る\"\r\n }\r\n}実務では、許可する項目をStrong Parametersで明示します。RubyのHashやparamsの扱いに慣れておくと、APIで受け取るデータ構造を読みやすくなります。
\ndef article_params\r\n params.require(:article).permit(:title, :body)\r\nendRails APIを実務で使う時は、Controllerの書き方だけでなく、認証、CORS、レスポンス形式を先に設計しましょう。APIはフロントエンドや外部サービスから呼ばれるため、画面表示中心のRailsとはつまずきやすいポイントが変わります。
\nAPIでは、session cookie、token、JWT、OAuthなど、構成に応じて認証方式を選びます。SPAやスマホアプリから呼ぶ場合は、どこに認証情報を持たせるか、ログアウトやtoken更新をどう扱うかまで決める必要があります。
\nReactやVueなど別ドメインのフロントエンドからRails APIを呼ぶ場合、CORS設定が必要になることがあります。ローカル開発では動いても、本番ドメインでブロックされることがあるため、許可するorigin、method、headerを早めに確認しましょう。
\nrender json: article は最初の学習には分かりやすいですが、実務ではそのまま全カラムを返すと不要な情報まで含まれることがあります。返す項目、ネスト、日付形式、エラー形式を統一するために、serializerや専用のJSON整形クラスを使う設計も検討しましょう。
Rails APIモードは、RailsをバックエンドAPIとして使い、画面側を別の技術で作る場合に向いています。特に、次のような構成ではAPIモードを検討しやすいです。
\n一方で、ブログ、管理画面、社内ツールのようにRailsでHTML画面まで作る方が速い場合は、通常のRailsアプリの方が合うこともあります。APIモードは「モダンだから使う」ではなく、アプリの構成に合わせて選びましょう。
\nRails APIの実務では、JSONを返すコードだけでなく、API設計、DB設計、認証、テスト、運用まで見られます。Rails APIモードを学ぶなら、CRUDを作った後に、実務で必要になる周辺スキルまで広げると案件で説明しやすくなります。
\n| スキル | \nRails APIで使う場面 | \n学習時に確認すること | \n
|---|---|---|
| REST API設計 | \nエンドポイント、HTTPメソッド、ステータスコードを決める | \nURL設計とレスポンス形式を説明できるか | \n
| Active Record | \nDBから取得したデータをAPIレスポンスに使う | \nN+1、scope、validationを理解しているか | \n
| 認証・認可 | \nログインユーザーごとに返すデータを制御する | \ntoken、権限、エラー時のレスポンスを設計できるか | \n
| テスト | \nAPIの正常系・異常系を検証する | \nrequest specでstatusとJSONを確認できるか | \n
| 運用・ログ | \n障害時に原因を追跡する | \nログ、監視、例外処理を考えられるか | \n
Rails APIのスキルを実務でどう使うか知りたい方は、Ruby on Rails案件一覧で、API開発、バックエンド開発、認証、DB設計、テストなどがどのように募集要件に入っているか確認しておくと、学習する範囲を決めやすくなります。
\nRails APIを初めて学ぶなら、小さなCRUD APIから始めるのが一番分かりやすいです。いきなり認証や複雑なserializerを入れるより、まずはRailsがJSONを返す流れを体験しましょう。
\nrails new my_api --api でAPIアプリを作るresources でRESTfulなroutesを書くrender json: で一覧・詳細を返すPOST / PATCH で作成・更新を作るRubyの配列変換や整形に不安がある場合は、Rubyのmapメソッドのような基礎文法も合わせて確認しておくと、APIレスポンスの加工が理解しやすくなります。
\n初期状態ではViewやhelperなどの生成が省かれますが、必要な機能を追加して使うことはできます。ただし、HTML画面をRailsで多く作るなら、最初から通常のRailsアプリとして作る方が自然な場合があります。
\n使えます。APIモードはView周りを軽くする構成であり、Active Record、マイグレーション、バリデーションなどのDB関連機能はRailsのバックエンド機能として利用できます。
\n使えますが、通常の画面ログインとは設計が変わることがあります。SPAやスマホアプリと接続する場合は、session cookieで扱うのか、tokenやJWTを使うのか、フロントエンド側の保存方法まで合わせて決める必要があります。
\nまずREST APIで十分かを考えましょう。Rails APIモードはREST APIを作りやすい構成です。クライアントごとに取得項目を細かく変えたい、複雑なデータ取得を1回のリクエストで扱いたい場合はGraphQLも候補になります。
\nRailsのMVCやHTTPの基礎を学びながらならおすすめです。ただし、APIモードでは画面が自動で表示されないため、JSONレスポンス、HTTPステータス、フロントエンドとの接続を意識する必要があります。最初は小さなCRUD APIから始めましょう。
\nRails APIモードは、RailsをJSON APIのバックエンドとして使うための構成です。rails new my_api --api で作成でき、通常のRailsアプリよりView、helper、assetsなどのブラウザ向け機能を絞った状態で始められます。
Rails APIを理解するには、通常Railsとの違い、ActionController::API、render json:、RESTful routing、Strong Parameters、HTTPステータスを順番に押さえることが大切です。実務ではさらに、認証、CORS、serializer、request spec、ログや監視まで求められます。
まずは小さなCRUD APIを作り、JSONの返し方とエラー時のレスポンスを整理しましょう。そのうえで、Ruby on Rails案件一覧を確認すると、Rails APIのスキルが実務でどのように評価されるか把握しやすくなります。
\n参考: Rails公式ガイド「Using Rails for API-only Applications」、Rails APIドキュメント「ActionController::API」
\n","protected":false},"excerpt":{"rendered":"Rails APIモードとは何か、通常のRailsアプリとの違い、rails new –apiでの作り方、JSONレスポンス、認証・CORSなど実務で注意するポイントを解説します。
\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[190],"tags":[286,275],"class_list":["post-96853","post","type-post","status-publish","format-standard","hentry","category-ruby","tag-ruby","tag-ruby-on-rails"],"aioseo_notices":[],"meta_description":"Rails APIモードとは何か、通常のRailsアプリとの違い、rails new --apiでの作り方、JSONレスポンス、認証・CORSなど実務で注意するポイントを解説します。","_links":{"self":[{"href":"https://freelance.indieverse.co.jp/media/wp-json/wp/v2/posts/96853","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https://freelance.indieverse.co.jp/media/wp-json/wp/v2/posts"}],"about":[{"href":"https://freelance.indieverse.co.jp/media/wp-json/wp/v2/types/post"}],"author":[{"embeddable":true,"href":"https://freelance.indieverse.co.jp/media/wp-json/wp/v2/users/1"}],"replies":[{"embeddable":true,"href":"https://freelance.indieverse.co.jp/media/wp-json/wp/v2/comments?post=96853"}],"version-history":[{"count":2,"href":"https://freelance.indieverse.co.jp/media/wp-json/wp/v2/posts/96853/revisions"}],"predecessor-version":[{"id":96855,"href":"https://freelance.indieverse.co.jp/media/wp-json/wp/v2/posts/96853/revisions/96855"}],"wp:attachment":[{"href":"https://freelance.indieverse.co.jp/media/wp-json/wp/v2/media?parent=96853"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https://freelance.indieverse.co.jp/media/wp-json/wp/v2/categories?post=96853"},{"taxonomy":"post_tag","embeddable":true,"href":"https://freelance.indieverse.co.jp/media/wp-json/wp/v2/tags?post=96853"}],"curies":[{"name":"wp","href":"https://api.w.org/{rel}","templated":true}]}}