API Meetup Tokyo #6での水野さんの講演資料です。ご本人から許可をいただいて掲載しています

1. Web API: The Good Parts 落穂ひろい
水野貴明
@mizuno_takaaki

2. 本日のお話
• APIリクエストの回数を減らす
• 非同期API
• SSKDs向けAPIとAPIバレ
• クライアントサイドとサーバサイドの役割分担

3. まずはじめに一言

4. まずはじめに一言
誤字脱字が多くて大変申し訳ありません

5. なぜ表紙は蛇なのか
Python関係のホント間違える人多数
息子が有毒性物を調べるのにハマっており、有
毒性物をリクエストしたらこうなった

6. 本書を書くにあたって
• コードを載せない
– コードを載せると分厚くなるし、特定の言語に寄って
しまう
– コードを載せるとAPIそのものの設計とは違うところに
目が言ってしまう危険性がある
• 言葉の細かい定義よりも使いやすさを
– RESTとはなにか、など
• 決定的な選択肢がない場合でも、自分なりの意
見を述べる
– The Good Partsシリーズを名乗る上での挟持

7. 本書で一番お伝えしたいこと
使いやすいAPIを
設計しよう

8. 使いやすいとは
• 意味がわかりやすい
• 一貫性がある
• 標準（デファクト・スタンダード含む）にそって
いる（ので類推がきく）
• クライアントが処理しやすい
• テストがしやすい
• ドキュメントがわかりやすい

9. 使いやすいとは
• RESUfulであることではない
• 自由度が高いことではない

10. APIリクエストの回数を減らす

11. APIはDBのインターフェイスではない
• users、items、photos、players … それぞれの
データを別々のエンドポイントに取得しに行く
のは大変
• モバイル・アプリ向けAPIは「1スクリーン、1
APIコール、1 セーブ、1 APIコール」
– http://wazanova.jp/items/1283
• クライアントが使いやすい、コール数が少なく
てすむデータ形式にすべき

12. チャンクでのAPI呼び出し
• 複数の処理をまとめて1回で呼び出す
• 結果もまとめて1回で返る
クライアント サーバ
リクエス
トC
リクエス
トB
リクエス
トA
レスポ
ンスC
レスポ
ンスB
レスポ
ンスA

13. 複数のIDを一度に取得
• https://api.example.com/v1/users/100,101
• https://api.example.com/v1/users?id=100,101
• https://api.example.com/v1/users?id[]=100&i
d[]=101

14. 非同期なAPI

15. 非同期なAPIとは
• リクエスト時に直ぐに結果が返らず、クライア
ントのリクエストした処理が完了するのにはそ
の後しばらく時間がかかる
• Job Queueシステムへのインターフェイス
• コールされてから結果を返すまでの処理が重
いケースに用いられる
– 課金処理
– データ集計処理

16. 非同期APIならではの設計ポイント
• どうやって処理の完了を知り、結果を取得す
るか
• クライアントからのリクエストと処理の結果を
どうやってひもづけるか

17. Push型
• 例: PayPalのAPI ( Mass Payなど )
• リクエストの際にはパラメータのチェックなど
最低限なもののみを行い、支払いができたか
どうかにかかわらずOKを返す ( OK = 受付完
了 )
• 予めクライアントが登録しておいたURIに
IPN(Instant Payment Notification)なるPOSTリ
クエストが飛んでくる
• そこで初めて成功失敗がわかる

18. Pull型
• FacebookのAds APIのレポート
• アクセスするとIDが取れる
• そのIDを使って結果取得用のエンドポイント
を叩く
• 処理が完了していたら結果が返る

19. PushとPull
• Pull型のほうがシンプルで実装が容易
– Pushだとアクセスに失敗した時のリトライ処理を
サーバサイドでも用意しなくてはならない
– Push型だとクライアントサイドのテストがやりづら
い
• PayPalはテストIPN送信ページを用意
– ところがすべてのIPNタイプに対応していない…

20. APIは隠してもバレる

21. APIは隠してもバレる
• 自分たちのウェブサイト/アプリのためにAPIを
作りたい
• 一般には公開しない
• でもサービスがメジャーになると、簡単にバレ
て解析される

22. 例.1 Vine

23. 例2. AirBnB

24. APIは隠してもバレる
• したがって一般公開しないAPI ( いわゆる
SSKDs 向け API) でもネット上に公開している
場合はセキュリティなどの問題はきちんと気
をつける

25. ちょっと違った事例
Twitter公式クライアントのコンシューマキー
• Twitterの公式クライアント(iPhoneやAndroid
など)のコンシューマーキーを解析して公開し
た人がいた
• このコンシューマーキーでアクセスすると、
Rate Limitが若干ゆるかった
• フリーミアムやユーザーの支払額に寄ってリ
ミットの量を変更している場合はこうしたリス
クもありうることを念頭に置く

26. WEB APIと SDK
あるいは担当をどこで分けるか問題

27. Web APIとSDK
あるいは担当をどこで分けるか問題
サーバ クライアントネット
ワーク

28. Web APIとSDK
あるいは担当をどこで分けるか問題
• 最もよくある形
サーバ クライアントネット
ワーク
開発者A 開発者B

29. Web APIとSDK
あるいは担当をどこで分けるか問題
• SDK
サーバ クライアントネット
ワーク
開発者A 開発者B
SDK

30. Web APIとSDK
あるいは担当をどこで分けるか問題
• オーケストレーション層
サーバ クライアントネット
ワーク
開発者A 開発者B
オーケス
トレー
ション層
内部ネットワーク

31. Web APIとSDK
あるいは担当をどこで分けるか問題
• APIアクセスを最適化する上でAPIのコール回
数を減らすのは重要
• ネットワークを境界にするとコールを減らす最
適化が行われづらい気がする
• Web APIをこう叩いて欲しい、こう叩きたいと
いう思想を一致させるためにはネットワーク
の両側を同じ開発者が担当するのもひとつの
解