Ruby RoguesメンバとiOSエンジニアのAPI議論

http://rubyrogues.com/147-rr-apis-that-dont-suck-with-michele-titolo/

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


Jshiike 3年弱前 | ▲upvoteする | link

iOSエンジニアのMichele Titoloは、Objective-Cのディペンデンシーを管理するCocoaPodsのプロジェクトで知られてますが、モバイルエンジニアの立場からAPIを利用して開発するポイントについても、自らのブログでまとめています。

1) Follow Conventions

はじめてのことにトライするときは先駆者の知恵に従うほうが、クオリティの高いものをつくれるので、conventionに従うのがよい。そのほうがデバッグもしやすい。自分でAPIのルールを定義する必要が生じた場合は、一貫性を維持してconventionにすること。誰が定義するにしろ一貫性が大事。

2) Don't Be Clever

人はとかく賢さを誇示したくなるものだが、ものすごく凝った仕様にすると物事が複雑になる。APIをつくるときはとにかくシンプルにすること。利用者の希望は、とにかく簡単にすぐアクセスすること。長い目で見ると、シンプルが一番。

3) Document, Document, Document

4) Expect the Unexpected

5年くらい使ってほしいとAPIを用意しても、途中でユーザは想定していなかった利用方法をとるもの。しかし、上記の3つのポイントをクリアしていれば対処できる。

そして今回は、Ruby Roguesのpodcastにゲスト出演して、APIについて更に議論しています。その中でいくつか面白かったポイントは、

"API first"のような動きがでてきているのは大歓迎だし、AppStoreにあるアプリのほぼ全ては何らかのAPI(この場合はweb API and/or ライブラリ)を利用しているが、まだ顧客企業は、マルチプラットフォームにしたいけどAPIを用意していないか、他の用途のAPIならあるのでこれをどうにかモバイルにも使えないか?という依頼がほとんど。しかも、セッティングがバラバラのときも多い。APIのconventionに従って、サイト全体で一貫性をもって提供すべき。urlの最後が.jsonならJSONを返すべきのように、世の中の常識的なものから、自分たちのルールでも決めたら一貫性をもって適用する。顧客企業には、3つのエンドポイントから異なるキーで同じオブジェクト、しかも返ってくるのがそれぞれ、id、product_id、productIDとか、という仕様になっていたところもあった。

paginationでurlを渡すときにheaderを使うLinkHeaderという仕様があり、webならデータの受渡しにフルheaderを利用するけど、モバイルだとデータの処理がwebクライアントとやや違うので、headerを使うべきか、レスポンスに情報を含みたいのか、どうするべきか同僚と議論になったことがある。永久スクロールを採用するなら、ユーザがどこのページにいるのかをトラックしなければいけないが、iOSならそれもview controllerがやるのか?別のオブジェクトが担当するのか?paginationをハンドルする特別なデータモデルを採用するのか? 永久スクロールという一つの機能のことだけでアーキテクチャ上の心配ごとが起きて、「一つのview controllerが全てを支配する。」という冗談もでる。view controllerが3万行になってた人もいた。もし、一つのエンドポイントがLinkHeader、もう一つがJSONを送ってくるようになってたら、平行して実装するか、両方をハンドルできるオブジェクトを用意するか、いずれにしてもつらい状況になる。サーバ側のAPIはこういう感じでモバイルのクライアントに影響を与えるので、(APIがあっても)実のところお互いはかなり密に結合していると同じことになる。

また、「シンプルであることは、最適化の敵になることがある。シンプルさを追求したAPIを用意した結果、1000個のオブジェクトに対してそれぞれRESTコールをすることになって、レスポンスを待ってアプリが遅くなることはありえるが、どうバランスをとるか?」という質問に対して、

自分はモバイルの最初の画面の読込みは1回のAPIコールでできるようにしたいと思っている。この場合はAPIのカスタマイズが必要だが、それは最適化するためのバランスをどうとるかということ。

InstagramのAPIでタグ検索すると、Instagramのフィードビューが返ってくる。これも、必要なデータが取得でき、カスタマイズされているが、パフォーマンスよいというバランスのとれた事例。

メトリックスのダッシュボードをつくるときは、キャッシュレイヤを用意してパフォーマンスを担保するという方法もある。

検索のAPIも、q=something?かというと、eコマースではフィルタリングも併用することが多いので、postしてJSONを返すようにした方が、もっと色々記述できて便利。

次に、「途中から、AngularJSか、Ember.jsでつくろう、モバイルもやらなくていけないから同じAPIを共有しよう。」という話しになったときどうするかという質問に対して、

JavaScriptアプリ、モバイルアプリ、ダッシュボードをつくるとして、APIをデータにあわせて設計すると、全パターンが苦労をするようになる。ユーザエクスペリエンスが異なるものであれば、あるものには最適で、他にはひどいものに仕上がる。どのパターンもユーザエクスペリエンスが似ていれれば、うまく設計すれば大丈夫。

ここは、James Edward Grayが「SQL DBのシェルのようなAPI、つまりデータをどう保存しているかを反映させたAPIでなく、どのようにAPIが使われるのかを考慮してAPIをつくるべき。目の前にある問題を解決するという意味でcleverにするのはよいのでは。」ということで、 "Don't be clever" の例外として話をまとめてます。

Netflixはこのようなクライアント(web, モバイル、コンソール他)ごとの違いの話が山ほどあったので、「NetflixのAPIプラットフォーム 」で紹介したようなアーキテクチャにしてるんですね。

Podcastの最後では、固定URLでなくリンク関係でAPIを定義することにより、URLをハードコードしなくて済むので、APIの変更にもフレキシブルに対応できるとして、Hyper Media APIの話題にも触れてます。


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


#api #rails #ios

Back