モバイルAPIデザインのまとめ - ワザノバ | wazanova

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コールが増えると、クライアントのスピードが落ちる。また障害の可能性となるポ

[izumin5210]

“1スクリーン、1 APIコール、1 セーブ、1 APIコール”

[invent]

参考になる / モバイルAPIデザインのまとめ - ワザノバ | wazanova via @feedly

[yyamano]

APIのバージョンはペイロードごとに設定すべき。それが実際にクライアントを壊す原因になるから。

[kakkunpakkun]

RESTfulなAPIとそれらをいくつかまとめたような高レベルなAPIを準備したい

[masa-wo]

versioningは最近実感してるなあ。

[ka2nn]

DBスキーマのミラーみたいなRESTにこだわってた時に作ったAPIのクライアントを自分で作った時に結構辛かった思い出

[udzura]

“エンドポイントはカスタムメイド”

[takezaki]

いいね

[numanuma08]

Restがベストじゃないってのは思うなぁ

[unarist]

APIを呼ぶときに必要なリソースを指定して、サーバはそれらを全て用意してまとめて送り返す

[poppun1940]

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

[kasajei]

“ペイロード”

[peketamin]

“もしリスティングコールは戻ってきたが、トンネルに入って接続が切れたためFavoritedを受け取れなかったらどうするか？”

[sionsou]

参考になる

[nilab]

モバイルAPIデザインのまとめ - ワザノバ | wazanova

[kimutansk]

1スクリーン、1APIコール、1セーブ、1 APIコール／サーバ側でサードパーティAPIを扱う／ペイロードごとにバージョン設定／ビジネスロジックはサーバ側／APIはフル準備と。

[tilfin]

“APIはユーザエクスペリエンスに従ってデザインされるべき。”

[haru666]

末端の対応とか嫌で糞だるいのでなんでも一本化したくなりますな…なってないもの、うちにもいっぱいあるけどやっぱり端末ごとの対応はバッドプラクティスだよな…

[aodifaud09]

「ユーザは待ってくれない。300msで」そんなん知らんわ外部環境やん

[windish]

"ビジネスロジックはサーバに置かないと、更に大変になる"

[lesamoureuses]

“ルールは、「1スクリーン、1 APIコール、1 セーブ、1 APIコール」”

[koogawa]

サードパーティAPIはサーバ側で扱う

[hoisjp]

ほぼ同じようなことを考えてる。Restful APIに並列コールのラッパーがやっぱり固いのかな。

[koba04]

API設計の話

[zbih]

“今後は、iOS / Android / Webに加えてウェアラブルなどもでてくるので、ビジネスロジックはサーバに置かないと、更に大変になる” だよね