Ruby初心者がRailsとGrapeでREST APIを作る

Backbone.jsを使ったアプリケーションのバックエンドのAPIを作ることになった。普段サーバーサイドを書くときはPHPを使ってたけど、勉強も兼ねてRubyを使った。

Railsのお勉強

Rubyでアプリケーションを書くときはRailsを使うのが当たり前みたいになってると思う。Railsは以前少し触ってみたけど、よくわからなくなって結局やめてしまった。今回は、Ruby on Rails Tutorialを手を動かしながらやった。ほぼRuby初心者だったので、Rack？Rake？Bundler？Rspec？なにそれ状態だったけど、調べながらひと通りやってみた。Railsとその周辺の技術をふわっと理解することができた。Railsはそんじょそこらのフルスタックフレームワークよりもフルスタックで、学習コストがめちゃくちゃ高いと思う。

Grape

RubyでAPI作るのいろいろ調べてたら、Grapeっていうgemと出会った。GrapeはRubyでREST APIを作るのに特化したマイクロフレームワークで、Sinatraの影響を受けている。

class API < Grape::API
  prefix 'api'
  version 'v1', using: :path
  format :json

  resource :book do
    get do
      Book.all
    end

    delete ':id' do
      Book.find(params[:id]).destroy
    end
  end
end

このようにURLの構造に沿った記述ができ、直感的に書きやすい。公式ドキュメントがしっかりしているので、使い方は読めばだいたいわかると思う。作ったサンプルはGitHubにあげた。

Grapeが使いやすそうだったので、Railsを使わずにGrapeだけでAPIを作ろうと思ったけど、RailsのModel周り（ActiveRecordとかmigrationとか）が便利だったので、やはり組み合わせて使うことにした。Webフレームワークは「ルーティング+リッチなModel」ぐらいがちょうどいいと思う。ViewHelperとかいらない。

Front-end × Rails

最近Webフロントエンドの技術が発展していて、フロントエンドなエンジニアの人はそれぞれ自分のやりやすい環境を持っていると思う。例えば僕だと「HTMLはJade、CSSはStylusを使って、bowerでライブラリ管理して、Gruntかgulpでビルドする」とか個人で作る分にはしたい。RailsにはAsset Pipelineがあるから、Gruntを使いたいときはどうするんだろう。

だから、RailsというかバックエンドはAPIのみを提供し、クライアントでDOMを構築する方がフロントとバックエンドで完全に分業できるし、どっちのエンジニアにとってもいいと思う。

API設計

今回、はじめてバックエンドはAPIを提供するだけで、あとはクライアントでがんばるっていう開発をしている。始める前は「APIってControllerからViewを介さずにjsonで返すだけだろ」ぐらいに思ってたけど、全然そんなことなかった。

どこまでをクライアントで、どこからをサーバーのロジックとして持つのがいいのかよくわからない。ただCRUDだけ提供すると無駄にHTTPリクエストが増えるし、詳細な操作ができるAPIにするとRPCっぽくなる。今はそこらへんを思考錯誤しながら作ってる。

今回はクライアントとしてWebブラウザのみを想定してるけど、iOSやAndroidも使うこと想定したり、バージョニングを考慮すべきだろうと思う。設計考えるのおもしろいし、もっと勉強しないといけない。

参考にしたWebページたち

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)