Rails 5 によるAPIの概要・Rails API 5でJSON APIを構築
ご存知のように、API アプリケーションはブラウザにユーザー インターフェイスを持たず、代わりに JSON または XML データ ... のみが表示されます。したがって、API アプリケーションを作成する場合、ライターは、API を使用する開発者、特に QA をサポートするために添付されたドキュメントを作成する必要があります。 ドキュメントを作成するには多くの方法がありますが、最も簡単な方法は、たとえば Excel または Word ファイルに手書きで書き込むことです。この API が何のためにあるのか、それにアクセスするための URL は何なのか、リクエストを送信するデータは何か、返すレスポンス データは何なのかを指定してください... その後、必要に応じて開発者/QA 側に送信します。使う・読みます。 この方法は非常に手作業であり、多くの労力を要しますが、それらを使用する人にもたらされる価値は必ずしも高いとは言えません。なぜなら、単純に統一されたフォーマットがなく、情報が不足しやすいからです。
2021年06月10日
ご存知のように、API アプリケーションはブラウザにユーザー インターフェイスを持たず、代わりに JSON または XML データ ... のみが表示されます。したがって、API アプリケーションを作成する場合、ライターは、API を使用する開発者、特に QA をサポートするために添付されたドキュメントを作成する必要があります。 ドキュメントを作成するには多くの方法がありますが、最も簡単な方法は、たとえば Excel または Word ファイルに手書きで書き込むことです。この API が何のためにあるのか、それにアクセスするための URL は何なのか、リクエストを送信するデータは何か、返すレスポンス データは何なのかを指定してください... その後、必要に応じて開発者/QA 側に送信します。使う・読みます。 この方法は非常に手作業であり、多くの労力を要しますが、それらを使用する人にもたらされる価値は必ずしも高いとは言えません。なぜなら、単純に統一されたフォーマットがなく、情報が不足しやすいからです。
ご存知のように、API アプリケーションはブラウザにユーザー インターフェイスを持たず、代わりに JSON または XML データ ... のみが表示されます。したがって、API アプリケーションを作成する場合、ライターは、API を使用する開発者、特に QA をサポートするために添付されたドキュメントを作成する必要があります。
ドキュメントを作成するには多くの方法がありますが、最も簡単な方法は、たとえば Excel または Word ファイルに手書きで書き込むことです。この API が何のためにあるのか、それにアクセスするための URL は何なのか、リクエストを送信するデータは何か、返すレスポンス データは何なのかを指定してください... その後、必要に応じて開発者/QA 側に送信します。使う・読みます。
この方法は非常に手作業であり、多くの労力を要しますが、それらを使用する人にもたらされる価値は必ずしも高いとは言えません。なぜなら、単純に統一されたフォーマットがなく、情報が不足しやすいからです。
1. Rails 5 のAPI モードの概要

Rails 5 がついに正式にリリースされ、それで、使用する新しい追加機能を見てみましょう。
最初に話すのは、Rails 5 のAPI モードの登場です。これにより、以前にコントローラーに含める必要があった面倒なものを使用することなく、Web API を構築できます。
1.1 Web API とは
API は Application Programming Interfaces の略です。簡単に理解すると、2 つのソフトウェアが相互に通信できるインターフェースです。現在、Web API を構築する為に非常に一般的で使われ、モバイルアプリケーションやJavaScriptアプリケーションのバックエンドとして使用されています。Web API は、HTML の代わりに JSON (または XML) を使用することがよくあります。 JSON は、自動化されたクライアントにとって理解しやすく、使用しやすく、現在、使用する Web API で簡単に見つけることができます。

1.2 Rails5のAPIモードの起源
実際には、この機能はRails 5 に統合された Rails API プロジェクトです。
1.3 Rails 5 のAPI モードの使用方法
単純な Rails API のみのアプリケーションの作成は次のとおりです。
rails new my_app --api
--api を使用することで、生成されたアプリケーションはミドルウェアを削減し、ActionController::API によって ActionController::Base から継承する代わりに、ビュー/ヘルパー/アセットと ApplicationControllers も作成しません。その後、config/application.rb ファイルに追加され、アプリケーションが Web API のみになります。
# config/application.rb
MyApp モジュール
class Application < Rails::Application
config.api_only = true
end
end
そして、通常の RoR アプリケーションとまったく同じようにアプリケーションを簡単に開発できます。そのアプリケーションには、ビュー、ヘルパー、またはアセットはすべて既にクライアント内にあるため、何もありません。ビューの代わりに、おそらくシリアライザーのようなものを使用して JSON ドキュメントを構築します。
1.4 Sinatra や Grape の代わりに Rails API モードを使用するのはなぜ
Grape や Sinatra などのよりコンパクトでシンプルなものを使用するのではなく、Rails を使用して Web API を構築する理由をよく尋ねられます。フレームワークは小さなアプリケーションの構築に対応できますが、ORM、いくつかのビルダー、自動リロード機能などに加えて、使用するライブラリをすばやく見つけることができます。そして最終には、アプリケーションをさまざまなライブラリから構成された巨大な Rails アプリケーションに変えることができます。それは本当に悪いことではありません。このアプローチでは、使用する gem を正確に選択できます。しかし、Rails を使用することを決定することは、他の選択肢に対する適切な選択肢でもあります。さらに、Rails ハンドルには使用できるものがたくさんあり、別の小さなフレームワーク (セキュリティ、条件付き GET、キャッシングなど) を探す必要はありません。
1.5 Rails API モードはいつ使用する
アプリケーションが Web API である場合は、Rails 5 のAPI モードのみを使用したほうがいいです。これは、HTML を送信するのではなく、クライアントが簡単に使用でき、好んで使用できる JSON または XML を送信することを意味します。ラックミドルウェアは、パイプラインのデザインパターンの完全な実装であり、非常に重く、要求と応答のオブジェクト上で実行するためにRoRのに使用されています。
1.6 ミドルウェア

Rack ミドルウェアは、パイプライン設計パターンの完全な実装であり、要求および応答オブジェクトで実行するために RoR で非常に頻繁に使用されます。デフォルトでは、Rails API のみのアプリケーションには限られたミドルウェアが付属しています。これは、それらが不要な機能に削減されていることを意味します。 ミドルウェアの追加は、application.rb ファイルに宣言行を追加するのと同じくらい簡単です。 たとえば、API に Rack::Deflater を追加する場:
# config/application.rb
module Alexandria class Application < Rails::Application
config.api_only = true
config.middleware.use Rack::Deflater
end
次のコマンドを使用して、アプリケーションで使用されているミドルウェアを一覧表示できます。
2 . Rails API を構築するのはJSON API バージョン。
2.1 JSON API とは
JSON API は、リソースに対するクライアント要求を取得または変更する方法と、サーバーがそれらの要求をバックアップする方法の仕様です。
JSON API は、クライアントとサーバーの間で渡される要求の数とデータの量の両方を最小限に抑えるように設計されています。 この効果は、読みやすさと柔軟性を損なうことなく実現されます。
2.2 データをフォーマットする方法
api JSON シリアル化データ には、次のものが含まれている必要があります。
- JSOn API 応答のルート レベルは JSON オブジェクトです。
- このオブジェクトには、トップレベルのデータを持つキーが含まれます。
- キーには、レコードを表す単一の JSON オブジェクト、またはレコードを表す 。JSON オブジェクトのコレクションを指します。データが含まれます。
- JSON オブジェクトは、以下を含むレコードを表します。
- レコードの IDです。
- レコードタイプ、つまりposts や cats などのリソースの名前です。
- そのレコードのプロパティを表すキーと値のペアを含む JSON オブジェクトを指す属性キー。 ここに表示されるプロパティがある場合は、データをシリアル化する方法によって決まります。
- リソースと他の JSON API リソースとの間の関係を説明する JSON オブジェクトを指す関係のランダム キーです。
2.3 Rails 5 API に JSON API を実装する
gem install rails --pre
rails new catbook --api --database=postgresql
JSON API が進むべき道であり、データのフォーマット方法の基本的な理解ができたので、JSON API を構築してみましょう。
2.4 アプリ
Cat の関連のデータとその設定を提供する単純な Rails 5 API を構築します。したがって、私たちのアプリには の主2つ要なリソースがあります: 猫と趣味です。 猫は興味がたくさんあり、趣味は猫がたくさんいます。 私たちは多対多の関係を持っています。
- ステップ1: 開始する
Rails 5 での最初の実行:
次に、先に進み、ディレクトリに 入り 、Gemfile に次の gem を追加します。
gem 'active_model_serializers'
gem 'rack-cors'
次に実行します:
bundle install
次に、JSON API の API アダプターを設定する必要があります。 ファイルを作成する
config/initializers/active_model_serializer.rb
そして確立する:
ActiveModelSerializers.config.adapter = :json_api
これにより、Rails にデータを JSON API 形式でシリアル化するように指示します。
また、データを受信するとき (サーバーへの jhacsh POST データのとき) に JSON API を
受け入れるようにアプリに指示する必要があります。 同じファイルに次を追加します。
api_mime_types = %W(
application/vnd.api+json
text/x-json
application/json)
Mime::Type.register 'application/vnd.api+json', :json, api_mime_types
最後に CORS を設定することを忘れないでください。 Rack-cors gem を使用しています。
- ステップ2:ドメイン モデル
Cat、Hobby、Cat Hobbies のリソースを作成します。 次のプロパティを持つ Cat に移行します。
class CreateCats < ActiveRecord::Migration[5.0]
def change
create_table :cats do |t|
t.string :name
t.string :breed
t.string :weight
t.string :temperament
t.timestamps
趣味:
class CreateHobbies < ActiveRecord::Migration[5.0]
def change
create_table :hobbies do |t|
t.string :name
t.timestamps
end
と猫の趣味:
class CreateCatHobbies < ActiveRecord::Migration[5.0]
def change
create_table :cat_hobbies do |t|
t.references :cat, index: true
t.references :hobby, index: true
t.timestamps
end
次に、関連付けを使用してモデルを設定します。
# app/models/cat.rb
class Cat < ApplicationRecord
has_many :cat_hobbies
has_many :hobbies, through: :cat_hobbies
end
# app/models/hobby.rb
class Hobby < ApplicationRecord
has_many :cat_hobbies
has_many :cats, through: :cat_hobbies
end
# app/models/cat_hobby.rb
class CatHobby < ApplicationRecord
belongs_to :cat
belongs_to :hobby
end
- ステップ 3: ルートとコントローラー
次の方法でルーターの名前空間を設定します。
Rails.application.routes.draw do
namespace :api do not
namespace :v1 do you
resources :cats, except: [:new, :edit]
resources :hobbies, except: [:new, :edit]
end
およびコントローラー構造:
├── app
├── controllers
├── api
└── v1
├── cats_controller.rb
└── hobbies_controller.rb
├── application_controller.rb
Cat Hobbies ルーターの定義がないことに注意してください。 これは、このデータを使用するユーザーは、関連する猫と趣味、および関連する趣味と猫を表示する必要がありますが、猫の趣味は表示する必要がないためです。
- ステップ4: シリアライザー と JSON レンダリン
顧客が猫に関する記録を要求する場合、関連する趣味の記録も含めたいと考えています。
実際、そのデータをサイドローディングしたいと考えています。
これは、顧客が猫の記録を要求したときに、特定の趣味または関連する趣味の記録全体を含めることを意味します。
2.5 猫のシリアライザ
次に、猫のプロパティとそれに関連する趣味をシリアル化するために、猫のシリアライザーを定義します。
class CatSerializer < ActiveModel::Serializer
attributes :id, :name, :breed, :weight, :temperament
has_many :hobbies
end
これにより、Rail は cat にレコードを提供するときに、関係するデータを説明する関係のキーを含めるように指示します。 したがって、次のように Cats#index を定義するとします。
module Api
module V1
class CatsController < ApplicationController
def index
render json: Cat.all
各猫の関連する趣味のデータを説明するキーの関係が存在することがわかります。 しかし、まだデータをサイドローディングしていません。 ここには実際の趣味の記録はありません。データをサイドローディングするには、コントローラーに追加する必要があります。
render json: Cat.all, include: ['hobbies']
これで、猫のリクエストに関連する実際の趣味の記録を含むトップレベルのキーができました。
2.6 最適化: N+1
ただし、このデータは、各猫の好みのリクエストを1つずつデータベースに送信するため、現時点では読み込みが少し遅いです。 次の2つのデータベース リクエストを行っています。
Cat Load (0.4ms) SELECT "cats".* FROM "cats" INNER JOIN "cat_hobbies" ON "cats"."id" = "cat_hobbies"."cat_id" WHERE "cat_hobbies"."hobby_id" = $1 [["hobby_id", 1]]
これをきれいにして、猫に関連するすべての設定について、データベースに1回だけクエリを実行します。
コントローラーのレンダリングを変更します。
render json: Cat.includes(:hobbies), include: ['hobbies']
これにより、データベース内のクエリが次のように変更されます。
2.7 ホビーシリアライザ
Hobby レコードで提供されるデータには、関連する猫の説明データを指すキー関係が含まれていることに気付いたかもしれません。
それは、私のホビー シリアライズをセットアップしているからです。
class HobbySerializer < ActiveModel::Serializer
attributes :id, :name
has_many :cats
end
または、ホビー コントローラーで以下を使用して、ホビーのリクエストに応じて、Cat レコード フォレストが含まれる ことを確認できます。
3. まとめ
多くのテスト バージョンを使用した長い開発期間を経て、数百人の開発者と数千のコミットを備えた Rails 5.0 は、これまでで最も安定した完全な Rails バージョンの 1 つになりました。
Rails 5.0 のリリースは、Rails コミュニティが依然として非常に強力に維持および発展していることを証明しています。
オフショア開発をご検討されている方々はぜひ一度ご相談ください。
※弊社の連絡先は以下の通り
アカウントマネージャー: クアン(日本語・英語対応可)
電話番号: (+84)2462 900 388
お電話でのご相談/お申し込み等、お気軽にご連絡くださいませ。
- オフショア開発
- エンジニア人材派遣
- ラボ開発
- ソフトウェアテスト
電話番号: (+84)2462 900 388
メール: contact@hachinet.com
お電話でのご相談/お申し込み等、お気軽にご連絡くださいませ。
無料見積もりはこちらから
Tags
ご質問がある場合、またはハチネットに協力する場合
こちらに情報を残してください。折り返しご連絡いたします。
関連記事
React Nativeは衰退するのか?Flutter時代における進化と将来性を技術的に整理
モバイルアプリ開発では、iOSとAndroidの両方に対応するクロスプラットフォーム技術が広く利用されています。その代表的なフレームワークの一つがReact Nativeです。しかし近年はFlutterの急速な普及により、「React Nativeは衰退するのではないか」という議論も見られるようになりました。一方でReact Nativeはアーキテクチャの刷新を進めており、現在も多くの企業で利用されています。本記事ではReact Nativeの技術的特徴や課題、新アーキテクチャによる改善、そして市場動向を整理しながら、現在の立ち位置と将来性について解説します。
FlutterでiOSアプリは本当に通用するのか:Dartの実行構造・描画エンジン・ネイティブ連携を技術的に検証する
近年、モバイル開発の現場ではFlutterの存在感が急速に高まっている。特にスタートアップや小規模チームでは「FlutterでiOSとAndroidを同時に開発する」という選択が現実的になりつつある。しかしエンジニアの視点から見ると、本当に重要なのは「Flutterが便利かどうか」ではなく、「その技術構造がiOSアプリ開発としてどこまで適しているか」である。ここで重要になるのが、Flutterの実装言語であるDartの役割だ。iOS開発と言語という観点で考えると、DartはSwiftのようなネイティブ言語とは根本的に異なる位置にある。本記事ではDartのAOTコンパイル、Flutterの描画エンジン、ネイティブAPIアクセスの仕組みを具体的に整理しながら、DartがiOS開発においてどこまで実用的なのかをアーキテクチャレベルで検証していく。
iOS 開発 言語の全体像:ネイティブだけでは語れない時代へ
iOSアプリ開発では長い間、SwiftとObjective-Cといったネイティブ言語が中心でした。しかし近年はFlutterやReact Native、Kotlin Multiplatformなどのクロスプラットフォーム技術も実務で使われるようになり、「iOS開発と言語」の関係は以前よりも多様になっています。本記事では、iOS開発で実際に使われる主な言語を整理しながら、ネイティブ開発とクロスプラットフォームの違い、アプリ開発における言語スタックの考え方、そして現在の技術の棲み分けについて技術者視点で解説します。
ネイティブかクロスかを構造で決める:実行経路・描画負荷・保守負債まで掘り下げるiOS技術比較
iOS開発と言語を検討する際、多くの記事は「開発効率」や「トレンド」で語られがちです。しかし技術者として本当に見るべきは、実行経路の長さ、コンパイル方式、UIレンダリング構造、依存レイヤーの数、そして長期保守時に発生する変更コストです。ネイティブ開発とクロスプラットフォーム開発の違いは思想ではなく、アーキテクチャ上の距離と制御範囲の差です。ここでは実装レベルまで踏み込みます。
Dartは本当に就職に強いのか?Flutter求人の構造・年収帯・生存戦略まで踏み込んで解説
Dart入門と検索する段階で、多くの人はすでに疑問を持っています。「学びやすいらしいが、それで就職できるのか」。結論を先に言えば、Dartは単体では市場価値を持ちません。評価対象はあくまで Flutter です。本記事では、日本・ベトナム・欧米市場の採用構造を具体的に分解し、年収レンジ感やスキル要件まで踏み込んで現実的に整理します。
Flutterで頭打ちになる人が見落としているDart基礎設計の決定的差
Flutterは学習初期の成功体験が早い技術です。しかし半年後、コードが肥大化し、再利用できず、状態管理が複雑になり、自分でも触りたくないプロジェクトになるケースは少なくありません。その分岐点はDart理解の深さです。Dart 入門レベルの文法理解で止まり、言語仕様や実行モデルに踏み込まなかった人ほど設計が破綻します。本記事では「なぜDart理解が不足するとFlutter開発が不安定になるのか」を技術構造レベルで解説します。
Dartのオブジェクト指向は「設計しない」ことで成立している
Dartのオブジェクト指向は、学習段階では拍子抜けするほど単純です。しかし実務で数万行規模になると、多くの言語で起きる「設計崩壊」が、Dartでは驚くほど起きにくい。本記事では、その理由を「美しい設計論」ではなく、どこで壊れ、どこで踏みとどまるのかという実装結果ベースで掘り下げます。
