モバイルAPIデザインのまとめ

http://natashatherobot.com/mobile-api-design/

1 comment | 1 point | by WazanovaNews 約3年前 edited


Jshiike 約3年前 edited | ▲upvoteする | link

Natasha Murashevがブログで、API Strategy and Practice Conferenceにおける、Michele Titolo (先月、「 Ruby RoguesメンバとiOSエンジニアのAPI議論」で紹介しました。)とEtsyのPaul Wrightの講演のポイントをまとめてくれています。

1) スピード

  • ユーザは待ってくれない。300msで、リクエスト / レスポンスの処理 / ユーザに結果の表示をする。

2) RESTが常にベストとは限らない

  • 以前のEtsyのAPIリソースはDBスキーマのミラーになっていた。クライアントがリスティングのリストを受け取ったら、ユーザがFavoritedに指定しているリスティングIDを取得するために、再度APIコールする必要があった。クライアントのAPIコールが増えると、クライアントのスピードが落ちる。また障害の可能性となるポイントが複数あるということ。もしリスティングコールは戻ってきたが、トンネルに入って接続が切れたためFavoritedを受け取れなかったらどうするか?データの同期の問題で、クライアントのロジックを複雑にするはめになる。
  • オブジェクトも同じ。もしユーザがクライアントにオブジェクトのリストを表示し、まとめて全てを修正したら、各リスティングをセーブするために複数のAPIコールをする替わりに、同時に全てのリスティングをセーブする1回のコールをする必要がある。その場合、一度に1件のリスティングだけがセーブされると、セーブできないリスティングが発生する可能性があり、クライアントとDBのデータが同期してない状態になる。
  • APIはユーザエクスペリエンスに従ってデザインされるべき。ルールは、「1スクリーン、1 APIコール、1 セーブ、1 APIコール」。
  • 現在のEtsyのAPIはDBスキーマから独立したドメインリソースになっている。ユーザがリスティングをリクエストしたら、クライアントで必要な可能性が高いので、画像URLがリスティングとともに返ってくるようになった。RESTful APIだと5回のコールが必要だったかもしれない仕組みが、新しいリソースオブジェクトではもっとまとめて戻ってくる。

3) 柔軟な仕組み

  • 新しいEtsyのAPIのエンドポイントはカスタムメイドできるようになっている。クライアントはAPIコールで必要なリソースを定義することができ、サーバはDBから並列作業でリソースを取得し、一つのレスポンスにまとめてクライアントに返す。クライアントからすると「1 スクリーン、1 コール」、サーバからすると複数のコールだが、まとめて処理するので、APIコールのスピードは担保される。
  • プロダクトは時間がたてば変更が入るので、アプリの機能も可変な仕組みであるべきで、そうすれば変化に早く対応できる。

4) サーバ側でサードパーティAPIを扱う

  • 例えば、メールを送るトリガーにSendgridのAPIを利用するとする。サードパーティであるSendgridへのAPIコールはサーバ側で対応すべき。もしそうしなければ、iOS / Android / Webクライアントのあるサービスだと、3つの異なるAPIコールとなる。Sendgridのサーバがダウンしたとき、もしくはSendgridのAPIがアップグレードした場合は、三つのクライアントがそれぞれが対応しなくてはいけなくなる。
  • 最悪のケースは、ユーザがあるバージョンのSendgrid APIをダウンロードし、二度とアップグレードしなかった場合(Android Gingerbreadユーザとか。)。SendgridがそのバージョンのAPIを廃止にしたらアウトになる。
  • もしiOSクライアントでSendgrid APIのバグが発生したら、Appleのアプリ審査の間は修正が完了しないことになる。

5) ペイロードごとのバージョン

  • APIのバージョンはペイロードごとに設定すべき。それが実際にクライアントを壊す原因になるから。APIのスピード改善など、クライアントを壊さない改修は、バージョンを分ける必要はない。
  • APIのペイロードについて先に合意しておけば、クライアントのエンジニアはすぐに作業に取りかかれるので、DBクエリを調整しAPIのスピードアップをするのは後からでよい。そのほうがトータルの開発時間が短縮できる。

6) サーバ側のビジネスロジック

  • 今後は、iOS / Android / Webに加えてウェアラブルなどもでてくるので、ビジネスロジックはサーバに置かないと、更に大変になる。
  • かつてEtsy APIは、ユーザのタイプがpublic / member / shopのいずれかによって、異なるペイロードを返していた。クライアント側は、どのユーザタイプごとに表示するフィールドを変える必要があった。今では、API側が複雑なロジックを処理し、クライアントはユーザオブジェクトを受け取るだけの仕組みに改善した。
  • もしビジネスロジックがクラント側にある場合、もし社長が「パスワードは7桁から8桁に変更しろ!」と言ってきたら、サーバ側の変更とともに、全てのクライアントで同時に対応しなくてはいけなくなる。

7) フル機能対応する準備

  • モバイルアプリ版は最初は最低限の仕様でスタートするかもしれないが、いずれWeb版と同じ機能セットをもつようになる。その際にあらかじめAPIだけは用意しておくと、プロダクトマネジャーが「モバイルでxxの機能もできるようにしたい。」となってもすぐに対応できる。

Jan-Mar/2014: ワザノバTop25アクセスランキング


#api

Back