社内座談会イベント始めました 〜第1回「モバイルバックエンドのAPIを考える」
Tweet
こんにちは山田コーダーです。今回は、先日はじめた「カジュアルトーク」という社内イベントの紹介をしたいと思います。
ルールは至って簡単で、技術的テーマと司会者を決めてそのテーマについて語り合うだけ。ただし重要なポイントがあります。それは録音して社内に公開すること。参加者には予めこのことを説明しているので、テーマから脱線したり、否定的、悲観的な内容になることも防げます。
必要なものは以下の通りです。
- テーマ
- 司会者
- 参加者（司会者を含めて3名集まれば可能）
- 録音機器（今回はiPhoneのボイスメモを利用）
- 場所（社外が理想。なるべく静かな飲み屋で）
第1回は、テーマは「モバイルバックエンドのAPIを考える」
今回の参加者は以下の5名でした。
- Kさん（アプリ兼API開発者）
- Tさん（アプリ開発者）
- K2さん（アプリ開発者）
- Nさん（API開発者）
- 司会（API開発者）
さて、今回のカジュアルトーク、残念ながら会話の様子を写真に撮り忘れました…。というわけで、今回の会話にも登場する弊社の「コーデスナップ」というサービスが台湾で行ったイベントの写真を掲載しておきます。
※ほら、Facebookでシェアした時、画像の有無でクリック率が全然違うでしょ？
※「GIRLS CAMERA」も弊社のサービスです！
写真左でピースしてるのが、Kさん（アプリ兼API開発者）。リア充臭満載の写真ですが、弊社のエンジニアは、オタ、リア充、一般人がほぼ均等に構成されており、どのような方でも馴染みやすい環境になっていますので、入社希望者はご心配なく！
それでは本題、カジュアルトーク第1回「モバイルバックエンドのAPIを考える」の内容を以下にまとめましたので、興味があれば是非読んでみて下さい！
API開発で大変に感じてるところは？
Kさん（アプリ兼API開発者）
コーデスナップでは、画像APIの中にその画像の投稿ユーザーのオブジェクトを入れています。しかし、逆にユーザーAPIの中にそのユーザーの最新画像のオブジェクトを入れようとすると、親子親子の無限ループになってしまい、どう設計するか悩みました。
Nさん（API開発者）
Webと違い、アプリのアップデートの問題があるので簡単にAPIを変更できません。APIレスポンスに情報を追加すればいいだけなら追加しますが、そうするとどんどんレスポンスが大きくなっていきます。
司会（API開発者）
私がAPI開発を始めた頃は、Web開発と違ってJavaScriptやCSSが要らないので楽勝だと思っていました。しかし実際にやってみると、考える事がいっぱいあって驚きました。
Tさん（アプリ開発者）
初めは画面デザインに合わせて、APIのレスポンスを決めていましたが、画面をリニューアルした時に欲しい情報もガラっと変わってしまいました。画面に特化したAPIを作ると大変だと実感しました。
かと言って、シンプルなREST APIだと1画面の表示に何度もAPIを叩く必要があります。どちらの方法も一長一短で、両者の中間くらいの方法があればいいなと思っています。
ちなみに、IRORIでは最大で1画面に6つのAPIを並列で取得して、レスポンスが帰って来たものから順に表示しています。
Kさん（アプリ兼API開発者）
たとえば写真に「Good」が付きましたみたいな通知データでも悩みました。これはなんらかのAPIを叩いた時に、そのレスポンスの中に混ぜて返しています。以前は30分おきに通知データを返していたんですが、そうすると30分おきにサーバーが高負荷になりました。
司会（API開発者）
一定間隔の高負荷は、サーバーのモニタリンググラフをみると剣山みたいになりますよね。（笑）
バージョニングはどうしてる？
Kさん（アプリ兼API開発者）
API単位でバージョン情報を渡しています。
Nさん（API開発者）
私はURLで /v1/ というパスで区切っています。しかしv2に移すタイミングがつかめていません。現在は後方互換性のない変更の場合は単に別のAPIを用意しており、このバージョニングの仕組みを利用できていません。
司会（API開発者）
このやり方は、v1をv2にコピーすれば、基本的にはv1は壊れないし、if文の分岐が要らなくなるという利点もあります。
Kさん（アプリ兼API開発者）
でも、APIって日々改善するので、すぐにv10とかになりそう。
K2さん（アプリ開発者）
ところで、バージョンアップの通知とかはどうしてますか？
Tさん（アプリ開発者）
iOSはiTunes APIで通知してます。Androidはそういう仕組みがないので、自前でAPIを作って通知してます。
Kさん（アプリ兼API開発者）
ユーザーにバージョンアップを依頼する際は、バグフィックスとか我々側の都合ではなく、機能追加とかユーザーに納得してもらえるのが理想ですよね。
K2さん（アプリ開発者）
『WEB+DB PRESS Vol.82』が「Web APIデザインの鉄則」という特集でした。この中では、バージョニングは、互換性を失う変更でなければレスポンスの中に付け足しちゃえば？みたいな意見もありました。型が変わったりしてクライアントサイドでエラーが出る時にバージョンアップする、みたいな。
Kさん（アプリ兼API開発者）
前から思ってたけど、gitのリビジョンを指定してAPIサーバーを起動することとかできないんですかね？モデルもライブラリーも全部そのリビジョンにする。ただDB構成が変わったらアウトですが…。
司会（API開発者）
LingrというWeb Chatサービスを作っていたKenn Ejimaさんのバージョニングに関するブログが以前話題になりました。/v1/を作っても/v2/をつくるタイミングはなかなかないし、いざやってみると大変だと。結局、DBのスキーマが変わるとどうしようもなくなるので、if文で局所的に分岐していくのが、試行錯誤した結果、いちばんよかったと。
アップデートしてくれないユーザーを切る、という行為はできれば避けたいですが、ユーザーを切らないことによって開発の負担がかかり、本当に楽しんでくれるユーザーに機能をすばやく提供できないという問題もあると思います。その辺は、ある程度のルールと決断が必要ですよね。
RESTfulって、どう？
Tさん（アプリ開発者）
今利用しているライブラリーがPATCHメソッドをサポートしていないので、リクエストヘッダに入れてメソッドを上書きしています。そういう点で、ちょっと面倒なところはあります。
司会（API開発者）
RailsではPUTメソッドの代わりにPATCHが推奨されているんですよね。
K2さん（アプリ開発者）
Railsってそういう更新がアグレッシブですよね。
Nさん（API開発者）
アグレッシブな更新に対しては、RubyKaigiで紹介されていたRSpec 2.99というものを提供して、3に移行しやすくするというアイデアが面白かったです。
司会（API開発者）
Railsの開発者もREST支持者も命名や整合性に対するこだわりが強いですよね。でも綺麗なREST APIでは欲しいデータが取りにくいことがあります。これに対する良い答えってありますかね？
一同
ないですね。
Tさん（アプリ開発者）
以前は1画面は1 APIにすべきだという変な常識を持っていました。だけど他人のアプリの通信を確認すると、1画面中に複数のAPIを叩いていて、その常識は崩れました。これはリソース指向に近いやり方だと思います。
司会（API開発者）
普通に考えれば3秒のAPI × 1本というパターンと、1秒のAPI × 6本だと、前者の方が早い気がしますが、取得順に描画していくことで体感スピードは後者の方が良くなる、ということも起こりえます。
Nさん（API開発者）
レスポンスが大きいとサーバーとクライアントの結合度が増える気がします。できるだけ粒度の小さいリソース単位でやりとりすると、後々使い回しもできていいんじゃないでしょうか。
あと、何を表示すべきなのか、というのも重要だと思います。これも欲しい、あれも欲しいでは、どんどん複雑になります。
司会（API開発者）
次の画面で欲しい情報を先読みしたい、とかになるとサーバー側がどんどん複雑になりますね。
Netflix社のエンジニアは、LSUD（large set of unknown developers 多数の未知の開発者）とSSKD（small set of known developers 小数の顔見知りの開発者）ではAPIの設計は全然変わってくる、ということを言っています。REST APIはLSUD向けで、SSKD向けのAPIは時にはRESTを崩してクライアントにとって都合のいいAPIを返すことも重要だと。
面白いのは、クライアントとベースのAPIの間にオーケストレーション層という中間層を設けて、その層の開発はクライアント開発者がGroovyで行うそうです。これはMongoDBのHTTP Interfaceを利用しているクライアント開発者がストアドメソッドをJavaScriptで書くのに似ています。社内Parse.comみたいだと言う人もいます。
JSON-RPC 2.0 / MBaaS / Parse.com
K2さん（アプリ開発者）
それってJSON-RPCみたいじゃないですか。JSON-RPC 2.0 Batchを使うと、小さなAPI群をひとつの固まりとして返してくれます。でもその中に一つ遅いAPIが混ざると全体的に遅くなるので注意が必要です。
司会（API開発者）
先ほどのコーデスナップのお知らせ情報もJSON-RPC 2.0 Batchを使うといいかもしれません。JSON-RPCはWikipediaの日本語ページもなかったりしますが、2年後はみんな使ってるかもしれません。あるいは全然はやらないかもしれませんが。
Parse.comのようなMBaaSサービスはどうでしょう。スマホアプリ開発がこれで十分という状況になれば、とりあえず私とNさんは失業しますね。（笑）
もちろんParse.comではまだまだ不便なところがいっぱいあるでしょうけど、API開発者とのコミュニケーションが不要になるというメリットはとても大きいと思います。
以上です。API開発者、スマホアプリ開発者なら、「あるある！」という点が少なからずあったのではないでしょうか？
本トーク会は隔月予定ですので、次回は年末の開催になりますが、また簡単なレポートをお届けしたいと思います。
