Rails での JSON API 実装まとめ

前後リンク

Ruby on JSON

API Technologies

の図のような流れになるんですが、それぞれ見ていきます。

to_json (2011-2013 頃)

2011-2013 年頃、僕らはrender :json を使っていました。

render json: @user
render json: @user.to_json

としてUser#as_json やUser#to_json を利用します。

この頃はまだ SPA という言葉もなく、ネイティブアプリもそこまで流行っていなかったのでこれで十分だったのですが、どんどん API に世の中が寄っていき、限界を迎えます。

この頃のツラみ

JSON Template engines (2013-2015 頃)

JSON を組み立てる方法として、RABL や jbuilder といったJSON 用のテンプレートエンジンを使う方法が出てきます。

RABL: 2011年からある老舗の gem。独特の言語で記述する必要があるので学習コストが高め。

jbuilder: rails4 から標準になった。割と簡単に柔軟に書ける。

どちらも「JSON は view」という考え方で、controller では普通に model を assign して、view で JSON を render する。

この頃のツラみと解決

ActiveModelSerializers (2014-)

jbuilder は部分テンプレートのレンダリングが異常に遅く、例えばユーザデータ 200 件を含む JSON を返したいだけで 50ms 以上食われることがザラにあった。

このため、遅いところでは「インラインに展開する」とか「to_json を使う」とかを頻繁に行っていて、これを解決するために serializer 層が生まれた。

AMoS はその流れで出てきたライブラリで、

という serializer としてのメリットと、

という利点、あと何より速さで使われ出した。

render json: @user
class UserSerializer < ActiveModel::Serializer  attributes :id,             :name,             :birthday  def birthday    object.created_at.strftime("%Y/%m/%d")  endend

この頃のツラみと解決

Grape (2012-2014 頃)

この流れとは別に、Grape が存在しました。REST API を作成するためのマイクロフレームワークです。

class UserEntity < Grape::Entity  expose :id  expose :name  expose :birthdayend
class API < Grape::API  format :json  resources :users do    get ":id" do      present User.find(params.id), with: UserEntity    end  endend

grape の記法を学ばなければならず、学習コストは高い。DSL だけあって、API 定義 (Entity) と router は割と読みやすいので慣れれば楽かも。

この頃のツラみと解決

AMoS と同じように問題を解決しているんだけど、いかんせん独自フレームワーク、独自 DSL だったのがネックですね。Rails じゃないと使われないという悲しみがあるのでした。

JSON Schema (2014-2016 頃)

JSON Schema とは: JSON で表現されるデータに対してデータ定義する Schema を記述する仕組み。

超簡単な例だと以下のようなデータと schema 定義。(概念コードです

{  "id": 12345678,  "name": "Taro",  "birthday": "2000-01-01 00:00:00"}
properties:  id:    type: integer  name:    type: string  birthday:    type: date-time

この頃のツラみと解決

また、他に

といった辺りも大きなメリットです。

先駆者たち

DeNA、Cookpad 等。2014年の中頃辺りから盛り上がってきた。

API Description Language (2016-)

JSON Schema は基盤となり、JSON Schema の上で API を記述する言語が生まれてきます。

JSON Schema は「JSON の構造を定義できる」だけで、API として使う JSON」の定義はJSON Schema の上にもう一つレイヤーが必要。

そこで出てきたのが以下の諸々で、現在 5 派閥ぐらいありそうです。

だいたい全て

みたいな機能を備えてます。

この頃のツラみと解決

当時ツラかった内容が全て解決していますね。

参考URL

API Query Language (2016-)

GraphQL が爆誕します。

GraphQL は今までの流れでも解決できていない、「そもそも REST は本質的に難しくて徹底できない。RESTish が限界」ということを認めて、別のアプローチを取ります。

もちろんデメリットもあります。

詳しくは第 4 部The NEXT of REST で。

前後リンク