Ginza.rb 第27回 Web APIの四方山話の参加レポート

#Ruby on Rails

#勉強会

かんあきひで

2015.09.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Ginza.rb 第27回 Web APIの四方山話に参加してきました！
内容を簡単にレポートしたいと思います。

Ginza.rbとは

銀座周辺のRuby技術者たちのmeetupイベントです。最初はソースコードリーディングの会が多かったそうです。
そこから今回までに開発環境の話やAPIの話など沢山の面白い企画が作られてきました。

過去のイベント一覧

自己紹介

各自作成したmarkdownのプロフィールを写して、自己紹介を簡単にしていきました。
自己紹介タイムでは参加者の最近気になることが知れて面白いです。やはりJSはReactが人気、サーバサイドはElixirが注目されていました。

JSON APIのお話

講演者として今回招かれた川村徹(@tkawa)さんのお話からスタートしました。
川村さんはRESTful Web APIs 読書会、Sendagaya.rbの主催者の方です。

当日の資料です
 川村さんがるびまに書いたRails APIについての記事です

JSON API

JSON APIとは自由すぎるJSONのフォーマットを定義することを目的として作成されたものです。
json apiの公式サイト

以下のようなフォーマットです(当日の資料から使わせていただきました)。

GET /articles

{
  "links": {"self": "/articles"},
  "data": [{
    "links": {"self": "/articles/1"},
    "type": "articles",
    "id": "1",
    "attributes": {
      "title": "JSON API paints my bikeshed!",
      "body": "The shortest article. Ever.",
      "created_at": "2015-05-22T14:56:29.000Z",
      "updated_at": "2015-05-22T14:56:28.000Z"
    },
    "relationships": {
      "user": {
        "data": {"id": 42, "type": "users"}
      }
    }
  }]
}

GET /articles?include=user

{
  "links": {"self": "/articles"},
  "data": [{
    ...
    "relationships": {
      "user": {
        "data": {"id": 42, "type": "users"}
      }
    }
  }],
  "included": [{
    "links": {"self": "/users/42"},
    "type": "users",
    "id": 42,
    "attributes": {
      "name": "John",
      "age": 80,
      "gender": "male"
    }
  }]
}

JSON APIのメリット

JSON APIを使うことで以下のメリットがあります

GETだけでなくPOST/PATCH/DELETEの仕様も定義している
リンクをサポートしている
includeによる複合ドキュメント、field指定、コレクションのsort、page、filterの仕様を定義している
エラー時のフォーマットを定義している

すでに上記のフォーマットが定義されていれば、独自仕様のJSONを作成することなくすでに存在するフォーマットを元にJSONを作成できます。クライアント、サーバサイドともに共通認識ができるので設計、実装がやりやすくなります。

JSON APIに対応しているgem

現時点でJSON APIに対応したgemは以下のものがあります

active_model_serializers
roar
rabl

JSON API以外のJSONフォーマットは次のものがあるそうです

Collection+JSON
HAL(最近AWSで採用されたとのこと、有力候補?)
Siren
UBER

今後JSON APIのようなフォーマットが普及すれば、クライアントサイド、サーバサイドの開発者に共通認識ができることやアプリケーションのFW側でもフォーマット通りのJSONを出力出来るような実装が進み開発が簡単になるように思いました。

APIのドキュメントについて

JSON APIではドキュメントの生成は定義していないということから、APIドキュメントについての話になりました。参加者のみなさんは基本的にサーバサイドでAPIを作る側の人たちなのですが、クライアントサイド（開発者、デザイナーなど）にどうやってAPIのインターフェースを伝えるのがよいか意見が沢山出ました。

参加者の一人は「grape-swagger」というgemを使いRailsアプリケーションからドキュメントを生成し、デザイナーの方に展開しているそうです。

swagger公式サイトのデモ

swagger-uiを使えばドキュメントを見るほかに実際にAPIを叩いて結果を受け取ることも出来るので、クライアントサイドの開発者には非常に便利なツールだと思います。

他にもapiaryというツールの話もありました。こちらはAPI BlueprintというマークダウンでAPIのインターフェースを記述するフォーマットを利用したサービスです。

api blueprint公式サイト
 apiary公式サイト

ドキュメントからswaggerと同じくモックサーバが作れます。マークダウンで記述するというところが敷居が低くてプログラマ以外も触れるので面白いと思いました。

RailアプリケーションにAPIを追加した話

続いてGinza.rb主催者の@y_yagiさんが、もともとあったRailsのWebサービスにAndoroidアプリ用のAPIを足していったときの四方山話をしました。
当日の資料です

言語の選択

最初、Rails以外にGo、Elixirを使うことも検討したそうです。既存のmodelを流用できることを優先しRailsをそのまま使うことにしましたが同時アクセス数が多いサービスであればGoを使っていたかもとのことです。

構成

model/controllerの中にapiディレクトリを作成してAPIに関するファイルをまとめています。routes.rbもapiのnamespaseをつけて分けています。

使用したGEMについて

認証処理の実装を０からするのが大変だったことから、cookpadさんが作成した「Garage」を使用したとのことです。
Garageについての説明

Garageの特徴として次のことを挙げていました。

responseはクラスで定義する(jbuilderのようにviewで作成しない)
アクセス制御をinitilizerで定義できる

使ってみた感想として認証部分とJSONのレスポンスをまとめて管理できることが楽で良かった、一方で情報源が少ないことが辛いことだったそうです。

APIつくってきた今までの思い出

最後に参加者の@takeyuwebさんが今までAPI開発をしてきた中で辛かったことなどを話しました。
当日のスライドがないので詳しく書けなくて申し訳ないのですが、以前勤めていた会社でXML-RPCをつかったシステムを開発したこと（今も動いているそうです!）やActiveResouceの話をされました。現在はAPIの負荷テストに興味をもっているとのことです。