REST API FoR MOBILE

目的

モバイル向けAPI設計で

今一般にどのような手法が取られてるかの共有

今日紹介したい記事

Extending REST APIs with API Aggregator

記事の主題よりも、
モバイル向けAPIの提供の仕方の分類が秀逸

前提：時代はRESTだ

REST API は格好いい

GET /dogs/1234

しかし、純粋REST APIはChattyになる欠点がある

例：「AKB」の文字が含まれる楽曲に紐づくタイアップ一覧

GET /music/_search?query=AKB * 1回

結果：45件

GET /tieup/_search?tieup_id=XXX * 45回

1 + 45 = 46回のAPI呼び出し

現状イケてるサービスは
どうなってるか

例：twitter 開発コンソール出してページを開くと、

3回のAjax通信を行ってる

１回のAPI呼び出しですべて取ってくるのが理想だが、

PCの場合十分な帯域とレイテンシがあるので問題ない

しかし、モバイルの場合回線が厳しいのでそうは行かない

帯域は細く、

レイテンシは低く、

複数コネクションつなぐコストも高い

モバイルページの約80%はなんらかの形で複合リソースを
必要とするらしい（ソースURL忘れた）

そのため

あるページを描画するため専用にカスタマイズしたAPIを用意し、

ページ描画時にそれ1つを叩けばOKにする、というのは

ユーザビリティの点から見ると間違ってはいない
（開発効率・再利用性などはひどいけど）

こういったバックグラウンドがあるため、

どっかのシステムには
「このAPIにこれ足してくれあれ足してくれ・・・」
と要件が来るようだ

しかし、やっぱRESTがいい

REST APIを維持しつつ、モバイルに特化したAPIも提供するには
どうすればいい？

この問題に対する広く知られたpractice：

アプリ(モバイル)専用バックエンドサービスを置く

バックエンドサービスとREST APIサービスが同じデータセンター内なら通信コストはかなり低い

REST APIは汎用性を保ちつつ改良でき、
モバイル向けAPIとしてはそれ専用にまた改良し続けられる
（すみ☆わけ！）

だけど、バックエンドサービスってコストかかるよね

はい、そのとおりです。

なので、バックエンドサービスの代わりに
nginx + lua使ったAPI Aggregator使いましょうねってのが
この記事

このAPI Aggregator詳細は読めてないので
To Be Continued...