Rails

Rails考古学:WebAPIを取り巻く環境の変化とRailsの対応

去年調べごとしたときのメモ書きをせっかくなので公開。あまり真に受けずゆるい読み物としてお楽しみください。

Rail 1.0から干支を一回り
常に進化し、アップグレード地獄を引き起こしながらも 環境の変化に適応し続けてきたRails
今回はWebAPIに注目して時代の流れを追いながらRailsはどうだったかみていきたいと思います。
※僕の観測範囲と憶測によるものなので勘違いや抜けなどあればご指摘頂けるとありがたいです

Railsバージョン 機能
2005 1.0~1.2 ActionWebService (XML-RPC, SOAP Server / Client )
2007 1.2~ resources routes (REST)
2007 2.0~3.2 ActiveResource (REST API / ~3.0 XML / 3.1~ JSON )
2009 2.3のみ Rails Metal
2010 3.0~ Metal controller / ActionDispatch::ParamsParser
2016 5.0~ Rails API / Action Cable / parameter_parsers

APIの時代背景

2000年前後~

2005年頃~

  • Web 2.0
  • マッシュアップ
    • マッシュアップ(Mashup)とは、ウェブ上に公開されている情報を加工、編集することで新たなサービスとすること。 マッシュアップの語源は異なる音源からトラックの一部をそれぞれ取り出してミックスし、一つの曲にする音楽の手法である。ウェブにおけるマッシュアップも同様に複数の情報源からの情報から関連のあるものだけを取り出して加工し、一つのウェブサービスとして仕立てあげる。 マッシュアップが注目されるようになったのはさまざまな企業や団体が所有するデータベースを公開するWebAPIを整備するようになったためである。これにより情報技術に対する深い造詣がなくとも新たなサービスを立ち上げることができるようになった。
  • AJaxの発見(2005)
    • GoogleMapなどによりJavaScriptによる非同期通信の有用性が認識された
  • RESTをWeb APIに適用する考え方
    • 2006年にWEB+DB Pressでも特集が組まれはじめた
    • Web APIを用いれば,構築中のWebアプリケーションにGoogleやYahoo!の機能を簡単に盛り込むことができます。また,RESTというWebアプリケーション/Webサービスのためのアーキテクチャスタイルは,HTTPとURIの正しい使い方を教えてくれます。 http://gihyo.jp/magazine/wdpress/archive/2006/vol32
    • RESTful API
    • RESTの設計原則をWeb APIに適用したもの
    • オライリー本『RESTful Webサービス』
    • 複雑で重厚なXML-RPC/SOAPよりも開発しやすいREST
    • 複数のRESTfulアプリケーションによる分散システム
    • Twitter API
    • 2016年サービス開始
    • 当初から閲覧・投稿などの仕組みの多くをAPIで公開し話題に。多くのクライアントアプリが登場
  • Atom Publishing Protocol(2007)
  • OpenSocial API(2007)
    • SNSのためのWeb APIの標準規格としてGoogleがリリース
  • OAuth 1.0(2008)
    • APIアクセス権限の委譲についての標準規格を作ろうという流れ
  • HATEOAS(2008?)
  • JSON Schema draft 1 (2009)

2010年頃~

Ruby on RailsでのAPIサポート

ActionWebService

  • Rails 1.0~1.2
  • 略してAWS(Amazon Web Service登場は2006年)
  • Railsアプリケーションにおいて、SOAPプロトコルとXML-RPCプロトコルをサポート(『RailsによるアジャイルWebアプリケーション開発第2版』より引用)
    • RailsのブログアプリケーションにBlogger APIやmetaWeblog APIのサポートを追加
    • 独自のAPIを実装し、.NET開発者がAWSで生成されたWSDLからそのAPIを使うためのクラスを生成できるようにする
    • SOAPバックエンドとXML-RPCバックエンドを同じコードでサポートする
  • このプロシージャ呼び出しがあったらこのコードを呼ぶみたいな規約を整備した(うろおぼえ)

resources

  • Rails 1.2
  • RESTに対応するインタフェースの直接のサポートが追加されました。このバージョンでは、resourcesと呼ばれる、ルート機能のマクロの一種が追加されています。(『RailsによるアジャイルWebアプリケーション開発第2版』より引用)
    • RESTfulなルート一式を作成
    • 各RESTfulアクションに対して1つのアクション
  • respond_toブロック
    • リクエストした形式に基づくレスポンスの種類の選択

ActiveResource

  • Rails 2.0~3.2
  • ネットワークを介してリモートのモデルに接続して利用する
  • Railsのresourcesの作法に沿って作られたRESTful API
    • そうでない場合は設定を書くことで(ある程度)対応できる
  • アプリケーションを超えてActiveRecordと同様に扱える

Rails Metal

  • Rails 2.3 でcgiからRackベースに変更した際に抽象化レイヤとして導入された
    • Rails::Rack::Metal
    • Rack middleware あるいはRackアプリケーションをRailsに実装できるようになった
  • RailsのroutingやControllerをbypassして高速化する
  • Rails 3.0からは、Rackミドルウェアへの対応や、config/routes.rbでRackアプリケーションをマウントできるようになったので不要になった

Metal controller

  • Rails 3.0~
  • Rails Metalに替わって、最も簡単なControllerとしてActionController::Metalが追加された
    • ActionController::Metal is the simplest possible controller, providing a valid Rack interface without the additional niceties provided by ActionController::Base. http://api.rubyonrails.org/v5.1.4/classes/ActionController/Metal.html
    • コールバックやContent-Type制御、render、HTTP認証などActionController::Baseの多くの基本的な機能を省いたもの
    • モジュールの読み込みやビュー層を省略して高速化
    • ActionController::Baseの親クラスである

ActionDispatch::ParamsParser

  • Rails 3.0~4.2
  • Content-Typeに従ってリクエストボディのパーサーを選択させる機能
  • Web APIで生のJSONやXMLをPOSTで受け、paramsでアクセスできるようになった
    • それまではrequest.body.readで生の
  • Rails 5.0からはActionDispatch::Requestが受け持つようになった(parameter_parsers)

Rails API

  • Rails 5.0 でコアにマージされた
  • 通常のRailsアプリケーションからビュー層とビューに関係の深いいくつかのmiddlewareを取り除いて高速化を狙うというもの
    • ActionController::APIActionController::Baseと同じくActionController::Metalの子クラス
  • Metal Controllerと比べて、キャッシュやHTTPレスポンス、HTTP認証、URLヘルパーなどRailsらしい便利機能はそのまま

Action Cable

  • WebSockets

最近の細々したもの

ActionDispatch::IntegrationTest.register_encoder

  • Rails 5.0
  • ActionDispatch::Request.parameter_parsersとあわせて、Integration TestでAPIリクエスト&応答のテストを書きやすくなった
    • JSON.parse(response.body)などのようにする必要がなくなった

その他

  • 仕様の文書化
    • いろいろな試み
    • JSON Schema
    • Open API
    • Rails標準としてこれ、というのは今のところ無い
    • Gemsはありそう
      • Railsの外の世界とのやりとりになるので、Railsコアとして何かやるのはちょっと違うのかも?どうなのかな
      • Rails API などで基盤としては整えた感じ、あとの実装は案件によりけり
      • Rails中心で進められるプロジェクトかどうかでどう進めるかがちがう
      • Rails 中心ならRails RESTful規約でよいとおもう

自由な働き方をしたいRailsエンジニア募集

当社は自由に働けることを何より重視しているRuby on Rails受託会社です。

完全リモート、地方在住OK、完全フレックスで働きたいRailsエンジニアを募集中です。

週3日ぐらいからでも働けて、好きな日に開発できます。

一緒にRuby/Rails開発をしませんか?

自宅で黙々と開発したいRailsエンジニアを募集!フリーランスもOK! - タケユー・ウェブ株式会社のWeb エンジニア中途・契約・委託の求人 - Wantedly