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...

モバイルのためのREST API (Catty APIの話)

By kbigwheel

Made with Slides.com

モバイルのためのREST API (Catty APIの話)

  • 2,530

More from kbigwheel