Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Web API: The Good Parts 落穂ひろい
水野貴明
@mizuno_takaaki
本日のお話
• APIリクエストの回数を減らす
• 非同期API
• SSKDs向けAPIとAPIバレ
• クライアントサイドとサーバサイドの役割分担
まずはじめに一言
まずはじめに一言
誤字脱字が多くて大変申し訳ありません
なぜ表紙は蛇なのか
Python関係のホント間違える人多数
息子が有毒性物を調べるのにハマっており、有
毒性物をリクエストしたらこうなった
本書を書くにあたって
• コードを載せない
– コードを載せると分厚くなるし、特定の言語に寄って
しまう
– コードを載せるとAPIそのものの設計とは違うところに
目が言ってしまう危険性がある
• 言葉の細かい定義よりも使いやすさを
– RES...
本書で一番お伝えしたいこと
使いやすいAPIを
設計しよう
使いやすいとは
• 意味がわかりやすい
• 一貫性がある
• 標準(デファクト・スタンダード含む)にそって
いる(ので類推がきく)
• クライアントが処理しやすい
• テストがしやすい
• ドキュメントがわかりやすい
使いやすいとは
• RESUfulであることではない
• 自由度が高いことではない
APIリクエストの回数を減らす
APIはDBのインターフェイスではない
• users、items、photos、players … それぞれの
データを別々のエンドポイントに取得しに行く
のは大変
• モバイル・アプリ向けAPIは「1スクリーン、1
APIコール、1 セーブ...
チャンクでのAPI呼び出し
• 複数の処理をまとめて1回で呼び出す
• 結果もまとめて1回で返る
クライアント サーバ
リクエス
トC
リクエス
トB
リクエス
トA
レスポ
ンスC
レスポ
ンスB
レスポ
ンスA
複数のIDを一度に取得
• https://api.example.com/v1/users/100,101
• https://api.example.com/v1/users?id=100,101
• https://api.example...
非同期なAPI
非同期なAPIとは
• リクエスト時に直ぐに結果が返らず、クライア
ントのリクエストした処理が完了するのにはそ
の後しばらく時間がかかる
• Job Queueシステムへのインターフェイス
• コールされてから結果を返すまでの処理が重
いケース...
非同期APIならではの設計ポイント
• どうやって処理の完了を知り、結果を取得す
るか
• クライアントからのリクエストと処理の結果を
どうやってひもづけるか
Push型
• 例: PayPalのAPI ( Mass Payなど )
• リクエストの際にはパラメータのチェックなど
最低限なもののみを行い、支払いができたか
どうかにかかわらずOKを返す ( OK = 受付完
了 )
• 予めクライアント...
Pull型
• FacebookのAds APIのレポート
• アクセスするとIDが取れる
• そのIDを使って結果取得用のエンドポイント
を叩く
• 処理が完了していたら結果が返る
PushとPull
• Pull型のほうがシンプルで実装が容易
– Pushだとアクセスに失敗した時のリトライ処理を
サーバサイドでも用意しなくてはならない
– Push型だとクライアントサイドのテストがやりづら
い
• PayPalはテストI...
APIは隠してもバレる
APIは隠してもバレる
• 自分たちのウェブサイト/アプリのためにAPIを
作りたい
• 一般には公開しない
• でもサービスがメジャーになると、簡単にバレ
て解析される
例.1 Vine
例2. AirBnB
APIは隠してもバレる
• したがって一般公開しないAPI ( いわゆる
SSKDs 向け API) でもネット上に公開している
場合はセキュリティなどの問題はきちんと気
をつける
ちょっと違った事例
Twitter公式クライアントのコンシューマキー
• Twitterの公式クライアント(iPhoneやAndroid
など)のコンシューマーキーを解析して公開し
た人がいた
• このコンシューマーキーでアクセスすると、
Ra...
WEB APIと SDK
あるいは担当をどこで分けるか問題
Web APIとSDK
あるいは担当をどこで分けるか問題
サーバ クライアントネット
ワーク
Web APIとSDK
あるいは担当をどこで分けるか問題
• 最もよくある形
サーバ クライアントネット
ワーク
開発者A 開発者B
Web APIとSDK
あるいは担当をどこで分けるか問題
• SDK
サーバ クライアントネット
ワーク
開発者A 開発者B
SDK
Web APIとSDK
あるいは担当をどこで分けるか問題
• オーケストレーション層
サーバ クライアントネット
ワーク
開発者A 開発者B
オーケス
トレー
ション層
内部ネットワーク
Web APIとSDK
あるいは担当をどこで分けるか問題
• APIアクセスを最適化する上でAPIのコール回
数を減らすのは重要
• ネットワークを境界にするとコールを減らす最
適化が行われづらい気がする
• Web APIをこう叩いて欲しい、...
Upcoming SlideShare
Loading in …5
×

Web API: The Good Parts 落穂ひろい

6,725 views

Published on

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

Published in: Technology

Web API: The Good Parts 落穂ひろい

  1. 1. Web API: The Good Parts 落穂ひろい 水野貴明 @mizuno_takaaki
  2. 2. 本日のお話 • APIリクエストの回数を減らす • 非同期API • SSKDs向けAPIとAPIバレ • クライアントサイドとサーバサイドの役割分担
  3. 3. まずはじめに一言
  4. 4. まずはじめに一言 誤字脱字が多くて大変申し訳ありません
  5. 5. なぜ表紙は蛇なのか Python関係のホント間違える人多数 息子が有毒性物を調べるのにハマっており、有 毒性物をリクエストしたらこうなった
  6. 6. 本書を書くにあたって • コードを載せない – コードを載せると分厚くなるし、特定の言語に寄って しまう – コードを載せるとAPIそのものの設計とは違うところに 目が言ってしまう危険性がある • 言葉の細かい定義よりも使いやすさを – RESTとはなにか、など • 決定的な選択肢がない場合でも、自分なりの意 見を述べる – The Good Partsシリーズを名乗る上での挟持
  7. 7. 本書で一番お伝えしたいこと 使いやすいAPIを 設計しよう
  8. 8. 使いやすいとは • 意味がわかりやすい • 一貫性がある • 標準(デファクト・スタンダード含む)にそって いる(ので類推がきく) • クライアントが処理しやすい • テストがしやすい • ドキュメントがわかりやすい
  9. 9. 使いやすいとは • RESUfulであることではない • 自由度が高いことではない
  10. 10. APIリクエストの回数を減らす
  11. 11. APIはDBのインターフェイスではない • users、items、photos、players … それぞれの データを別々のエンドポイントに取得しに行く のは大変 • モバイル・アプリ向けAPIは「1スクリーン、1 APIコール、1 セーブ、1 APIコール」 – http://wazanova.jp/items/1283 • クライアントが使いやすい、コール数が少なく てすむデータ形式にすべき
  12. 12. チャンクでのAPI呼び出し • 複数の処理をまとめて1回で呼び出す • 結果もまとめて1回で返る クライアント サーバ リクエス トC リクエス トB リクエス トA レスポ ンスC レスポ ンスB レスポ ンスA
  13. 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. 14. 非同期なAPI
  15. 15. 非同期なAPIとは • リクエスト時に直ぐに結果が返らず、クライア ントのリクエストした処理が完了するのにはそ の後しばらく時間がかかる • Job Queueシステムへのインターフェイス • コールされてから結果を返すまでの処理が重 いケースに用いられる – 課金処理 – データ集計処理
  16. 16. 非同期APIならではの設計ポイント • どうやって処理の完了を知り、結果を取得す るか • クライアントからのリクエストと処理の結果を どうやってひもづけるか
  17. 17. Push型 • 例: PayPalのAPI ( Mass Payなど ) • リクエストの際にはパラメータのチェックなど 最低限なもののみを行い、支払いができたか どうかにかかわらずOKを返す ( OK = 受付完 了 ) • 予めクライアントが登録しておいたURIに IPN(Instant Payment Notification)なるPOSTリ クエストが飛んでくる • そこで初めて成功失敗がわかる
  18. 18. Pull型 • FacebookのAds APIのレポート • アクセスするとIDが取れる • そのIDを使って結果取得用のエンドポイント を叩く • 処理が完了していたら結果が返る
  19. 19. PushとPull • Pull型のほうがシンプルで実装が容易 – Pushだとアクセスに失敗した時のリトライ処理を サーバサイドでも用意しなくてはならない – Push型だとクライアントサイドのテストがやりづら い • PayPalはテストIPN送信ページを用意 – ところがすべてのIPNタイプに対応していない…
  20. 20. APIは隠してもバレる
  21. 21. APIは隠してもバレる • 自分たちのウェブサイト/アプリのためにAPIを 作りたい • 一般には公開しない • でもサービスがメジャーになると、簡単にバレ て解析される
  22. 22. 例.1 Vine
  23. 23. 例2. AirBnB
  24. 24. APIは隠してもバレる • したがって一般公開しないAPI ( いわゆる SSKDs 向け API) でもネット上に公開している 場合はセキュリティなどの問題はきちんと気 をつける
  25. 25. ちょっと違った事例 Twitter公式クライアントのコンシューマキー • Twitterの公式クライアント(iPhoneやAndroid など)のコンシューマーキーを解析して公開し た人がいた • このコンシューマーキーでアクセスすると、 Rate Limitが若干ゆるかった • フリーミアムやユーザーの支払額に寄ってリ ミットの量を変更している場合はこうしたリス クもありうることを念頭に置く
  26. 26. WEB APIと SDK あるいは担当をどこで分けるか問題
  27. 27. Web APIとSDK あるいは担当をどこで分けるか問題 サーバ クライアントネット ワーク
  28. 28. Web APIとSDK あるいは担当をどこで分けるか問題 • 最もよくある形 サーバ クライアントネット ワーク 開発者A 開発者B
  29. 29. Web APIとSDK あるいは担当をどこで分けるか問題 • SDK サーバ クライアントネット ワーク 開発者A 開発者B SDK
  30. 30. Web APIとSDK あるいは担当をどこで分けるか問題 • オーケストレーション層 サーバ クライアントネット ワーク 開発者A 開発者B オーケス トレー ション層 内部ネットワーク
  31. 31. Web APIとSDK あるいは担当をどこで分けるか問題 • APIアクセスを最適化する上でAPIのコール回 数を減らすのは重要 • ネットワークを境界にするとコールを減らす最 適化が行われづらい気がする • Web APIをこう叩いて欲しい、こう叩きたいと いう思想を一致させるためにはネットワーク の両側を同じ開発者が担当するのもひとつの 解

×