RailsでAPIサーバを開発する(AngularJS, Ruby on Rails, SPA)

RailsでJSONを返すAPIアプリケーションを３週間ぐらい試行錯誤しながら作成しています。少しですがノウハウも溜まってきたのでここにまとめておこうと思います。
今回のアプリケーションの構成は大体次のようになっています。

• RailsはAPIサーバ（一般公開するAPIではなくSPA(シングルページアプリケーション)のサーバとしてJSONを返却する。HTMLは返却しない）
• クライアントサイドはAngularJSで画面遷移、Viewの描画まで管理する
• DBはMySql、Session管理はRedis（まだローカル開発なのであまり関係無い）

チームはサーバサイド、クライアントサイドで完全に分担して二人で作成しています（自分はサーバサイド担当）。
このブログエントリーでは次のことを書きます。

• APIのルーティングの設定(JSONのみ返すようにする方法)
• Session管理（CSRFトークンの受け渡し方法など）
• APIのテスト方法(RSpecを使っています)

APIのルーティング

JSON　formatの指定

各Routingをnamespace :api {format: 'json'}を全体に囲みます フォーマットをjson固定で指定したので、URLに「.json」をつけなくてもJSONが返却されます。 （「/api/users」というURLでJSONが返却されます）

namespace :api, {  format: 'json' } do
  resources :admin_users
  resources :domains do
     resources :sites
  end
  post 'login' => 'user_sessions#create'
  delete 'logout' =>'user_sessions#destroy'
  route to: 'welcome#index'
end

Controllerのnamespace

routes.rbでapiというnamespaceで全体を囲んでいるのでControllerにもnamespaceを付けます。付けたnamespaceに合わせてディレクトリも作成します（app/controllers/apiディレクトリを作成）。

module Api
  class UsersController < ApplicationController
  
  def index
    @users = User.all
    render json: @users
  end
end

Session(Cookie)の管理

CSRF-Tokenとsession_storeについて書きます。

CSRF-Token

今回のアプリケーションではサーバサイドでViewをレンダリングしないので、そのままではクライアントとのCSRF−Tokenの受け渡しができません。
なのでトークンの受け渡しをするためにクライアント（今回はAngularJS）側で、リクエストヘッダーのX−CSRF-Tokenにサーバから渡されたトークンを設定してリクエストを送ります。
とりあえず開発フェーズでそこを後回しにしたい場合はCSRF-Tokenを無効にすることもできます。

module Api
  class ApplicationController < ActionController::Base
    protect_from_forgery with: :exception
    skip_before_filter :verify_authenticity_token    
  end
end

(protect_from_forgery with: null_sessionだとcookie自体が無効になってしまうのでこのように指定しています )

session_store

純粋なAPIサーバの場合、アクセストークンを発行して有効期限を設定するというやり方が一般的です。 ですが今回はSPA用のサーバとしてRailsアプリケーションをAPIサーバにしているだけなので、通常のRailsアプリケーションと同様にCookieを利用してSession管理をしています(session_idの受け渡し方法として)。
話はそれますが今回作成しているアプリケーションはsession_soreとしてRedisを使用しているのでそこの設定を書いておきます。

• session_store.rbに書いてある元の設定は削除する

  # Rails.application.config.session_store :cookie_store, key: '_spa-demo_session'

• 環境用設定ファイル(development.rb, production.rb)にredisの設定をする

  config.session_store :redis_store, {
                           key: '_spa-demo_session',
                           servers: {
                             host: 'localhost',
                             port: '6379',
                             db: '0'
                           },
                           expire_after: 60.minutes
                         }

APIのTest方法

spec/requestsを使ってテストします。今回のRailsアプリケーションは画面が無いためCapybaraは使いません。
コントローラのレスポンスをシュミレートするためにget、post、put、deleteメソッドを使います。
(以下はadmin_users_controller.rbというコントローラを作ったと仮定して、そのAPIに対するテストケースです)

一覧(index)API

describe 'GET admin_users API', type: :request do
  it 'populates an array of all admin_users and does not include delete_containers' do
    suzuki = create(:admin_user, user_name: "鈴木一朗", email: "suzuki@co.jp", container_nums: 5)
    yamada = create(:admin_user, user_name: "山田太郎", email: "yamada@co.jp", container_nums: 5)

    get "/api/admin/admin_users"
    expect(response.status).to eq 200
    expect(assigns(:admin_users)).to match_array([@admin_user, suzuki, yamada])
  end
end

• レスポンスオブジェクトのステータスフィールドを確認します。
• match_arrayメソッドで返却値の配列に作成したオブジェクトが含まれていることを確認します。なおmatch_arrayは順番は保証しないので、順番の確認が必要な場合は結果のJSON配列を確認する必要があります。

詳細(show)API

describe 'GET admin_users#show API', type: :request do
  before :each do
    @admin_user = create(:admin_user, id: 1)
    login @admin_user
  end

  it 'assigns the requested admin_user to @admin_user' do
    get "/api/admin/admin_users/#{@admin_user.id}", nil

    expect(response).to have_http_status(:success)
    json = JSON.parse(response.body)
    expect(json["id"]).to eq @admin_user.id
    expect(json["user_name"]).to eq @admin_user.user_name
    expect(json["admin_user_role_id"]).to eq @admin_user.admin_user_role_id
    expect(json["email"]).to eq @admin_user.email
  end
end

• 詳細APIではオブジェクトのそれぞれのフィールドを確認しています。responseオブジェクトのbodyフィールドをjsonオブジェクトに変換してから確認します。
• beforeメソッドのなかで実施している「login @admin_user」はこのAPIを表示するための認証処理をパスするために行っています（APIテストには直接関係ない処理ですが後で説明します）。

更新(update)API

describe 'PUT admin_users#update API', type: :request do
  before :each do
    @admin_user = create(:admin_user)
    login @admin_user
  end

  context "valid attributes" do
    it "changes admin_user's attributes" do
      updated_date = DateTime.new(2015, 7, 7, 11, 12, 13)
      admin_user = create(:admin_user,
                          id: 2,
                          email: "before@co.jp",
                          user_name: '変更前',
                          admin_user_role_id: 1,
                          updated_at: updated_date)
      new_attributes = { id: 2,
                         email: 'after@co.jp',
                         user_name: '変更後',
                         admin_user_role_id: 2,
                         updated_at: updated_date}
      put "/api/admin/admin_users/#{admin_user.id}", new_attributes
      admin_user.reload
      expect(response).to be_success
      expect(admin_user.email).to eq('after@co.jp')
      expect(admin_user.user_name).to eq('変更後')
      expect(admin_user.admin_user_role_id).to eq(2)
    end
  end
end

• APIをコールする時はリクエストパラメータをハッシュで指定するので、ここでもnew_attributesというハッシュを作成してputメソッドの引数に渡しています。
• putメソッド実行後、オブジェクトをreloadメソッドで更新して各フィールドがAPI実行後に期待値に変わったか確認しています

登録(post)API

describe 'POST admin_users API', type: :request do
  it 'creates admin_user' do
    params = { email: "test@co.jp", user_name: "テスト管理者", password: "password",
               password_confirmation: "password"}
    # 登録が成功してDBのレコードが一件増えていることを確認する
    expect {
      post "/api/admin/admin_users", params
    }.to change(AdminUser, :count).by(1)
     expect(response.status).to eq 201
  end
end

ここでは登録APIが成功していることを「expect { XXX }.to change(YYY).by(1) 」の箇所で確認しています。 私は今回のプロジェクトでほぼ初めてRSpecを使ったのですが、この書き方は最初ビビりました。。が、慣れてくると見やすいですね、多分。
これはRSpecのchangeというマッチャで次のように使います。

expect{ XXX }.to change{ YYY }.from(AAA).to(BBB)

XXXの処理をするとYYYのオブジェクトがAAAの状態からBBBの状態に変わることを期待する

削除(delete)API

登録とは反対に削除されることを確認するだけなのでコードは省略します。 changeマッチャを使って一件レコードが減っていることを確認すればよいだけです！

expect {
  delete "/api/admin/admin_users", id
}.to change(AdminUser, :count).by(-1)

認証チェックをパスしてテストする方法

先ほど詳細APIのところで少し触れた以下の記述ですが、これはAPIをテストするために認証処理をシミュレートをするための記述です。
認証処理にSorceryというgemを使用していますが、独自の認証処理でもあってシミュレートする仕組みは大体同じだと思います。

before :each do
  @admin_user = create(:admin_user)
  login @admin_user
end

1.ログインをシミュレートするためのモジュールの作成

「rspec/support」ディレクトリに「authentication.rb」というファイルを作成して次のように処理を書きます。

module Authentication
  def login user, password = 'password'
    user.update_attribute :password, password
    post '/api/admin/login', { email: user.email, password: password }
  end
end

• postメソッドの引数にはloginのパスを指定する
• emailではなくてユーザー名で認証している場合は{ user_name: user.name, password: password }にする

2.作成したモジュールを読み込ませる

rails_helperに今回作成したモジュールを追加してテスト実行時に利用できるようにします

RSpec.configure do |config|
  config.include Sorcery::TestHelpers::Rails::Integration, type: :request # 追加
  config.include Authentication # 追加
end

ここまでの設定をすれば、APIのテスト時に認証処理をパスすることができるようになります。

現段階でのAngularJS & RailsのSPAアプリケーションについての感想

最後にまだまだ触ったばかりでしっかりと理解はできていないのですがRailsとAngularJSによるSPAについての雑感です。
メリット次のようなものがあると感じています。

• サーバサイド、クライアントサイドにエンジニアを用意してチームを組めるのであれば分担して開発ができる
• クライアント開発（JS、デザイン)の実力者がいればその人の能力をフルに活かせる

一方デメリットはこんな感じでしょうか。

• 単純な画面（ログイン、一覧画面等）までクライアントサイドで全て作るのはむしろ生産性が下がる（気がする）
• APIのインターフェースが変更になるとどちらも影響を受ける

まだまだ始めたばかりなのでもう少しこのスタイルの開発を噛み砕いてきたらまた感想などを書きたいと思います。