YAPCレポート(3):モバイルアプリとAPI、“JSON Schema”の関係を考える #yapcasia

日頃からPerlばかりを書いているWebエンジニアのaonekoです。8月28日から3日間行われた世界最大規模のPerlカンファレンス「YAPC::Asia Tokyo 2014」について、すでに以下の2本のレポートがHRナビに掲載されていますが、本記事は、そのYAPCレポートの第3弾となります。

近年はスマートフォンアプリの普及によって、クライアントサイドからのWeb APIの利用や、ソーシャルログインの機会もだいぶ増えてきているのではないでしょうか。YAPCでも比較的初心者向けのAPI寄りのトークがいくつか見受けられましたので、それらを中心にレポート致します!

JSON SchemaとAPIテスト

DeNAのテストエンジニア清水直樹さんからJSON Schemaを利用するメリットに関する発表です。JSON Schemaとは、JSONで表現されるデータに対してデータ定義するSchemaを記述する枠組みで、json-schema.org で公開されており、現在draft4です。そして、これを用いてAPIの仕様を記載することが一部で流行になりつつある、との説明でした。

トーク冒頭では「JSON Schema」そのものの紹介をして、次に、API仕様をJSON Schemaで記述する利点について述べられました。JSONは機械にも人間にも読みやすいため、これがそのまま仕様になる上に、Validatorを使ってAPIサーバのリクエスト・レスポンスのSchemaとの整合性を機械的に検証することができる、という点が利点として挙げられていました。Validatorのライブラリとしては、Perlなら「perl-JSV」、Rubyなら「json-schema」などがあるようです。

このトークでの試みは「JSON Schemaで書かれたAPI仕様を用いて、正常系・異常系のリクエストデータを自動生成し、それをAPIテストの自動化に活用する」というものです。

JSON Schemaから、そのSchemeに対して正常系・異常系のデータを作成するRuby ライブラリ、json-fuzz-generatorを紹介していました。ここで、自動生成されたリクエストデータがテストケースとして十分か、といえばもちろんそんなことはありません。リクエストデータの生成において、ドメインの特性によるものはJSON Schemaからの自動生成は不可能ですし、レスポンスの検証においてもAPIのロジックに基づくものは同様です。しかし、これによって自動化できる部分は自動化してしまえば、人間にしか書けない部分のテスト、より高品質なテストや開発に集中できる。発表は、そんな風に結ばれていました。

モバイルアプリとAPIのありかたを考える2014

次は、あらたまさんからの発表で「モバイルアプリとAPIのありかたを考える2014」というトークです。

ユーザーの1アクションのたびに「通信中…」となるアプリがときどきあります。こういった問題を解決するには、という問いかけでトーク本編が始まりました。

あまりコストをかけることが出来ずに作ってしまったモバイルアプリのバックエンドのサーバーサイドが、サービス成長期においてボトルネックになる、というのは個人・小中規模でありがちな話のようですね。こうしたときに利用できるのがモバイルアプリのバックエンドをまとめて提供してくれる「MBaaS」(Mobile Backend as a Service)だそうです。発表では、その代表格であるParseについて紹介していました。トークンの保存やデータの同期のためだけにバックエンドを用意しなくてよくなるので、まさに小中規模アプリのプロトタイピングやスモールスタートに適したものとなっているようです。

また本トークでは、一度の通信で複数メソッドを実行することで通信コストを下げることができるJSON-RPC 2.0 Batchについても紹介されました。これを利用することによって、クライアントサイドもサーバサイドも複数の処理を組み立てやすい、コードの再利用性が高まる、などのメリットが挙げられていました。JSON-RPC 2.0 Batchに対応したiOSのAPI ClientであるCRSJSONRPCClientが、近日GitHubで公開予定らしいです!

OAuth/OpenID Connectを用いてID連携を実装するときに気を付けること

@ritouさんからの発表です。

このトークでは、Google+やFacebookなどとID連携をする、いわゆる「ソーシャルログイン」を実装するにあたり、サービス提供側が気を付けるべきことについて述べられていました。

ひとつはUX面での注意点です。「認証連携キャンセル時にはエラー扱いにはせず、再度認証連携をやり直せるようなフローにすべき」「連携済みユーザーが存在していなかった場合には、ユーザーに認証のやり直しをさせずにうまく最短経路で登録へと誘導すべき」、といった点が述べられていました。

もうひとつはセキュリティ面の話です。Webアプリの場合、リダイレクトURIのクロスドメインCSRF対策が必要なことが強調されていました。これをしないと第三者のアカウントと紐づくような攻撃が考えられますが、セッションと紐づくようなstateパラメータを検証することで対策できる、と述べられました。ただし、stateパラメータにセッションIDそのものを利用してはいけません。ネイティブアプリの場合は、各サービスのiOS SDKやAndroid SDKなどで取得したアクセストークンをバックエンドのサーバに送信するのですが、この場合には、トークン置換攻撃のリスクがありますので、バックエンドサーバは必ずそのアクセストークンが自らのアプリ(client_id)に対して発行されたものである、ということを確認しなければならない、という点について強調されていました。

レポートの続きはこちら → YAPCレポート(4):DeNAが歩んだデプロイ自動化への道