Downloaded 37 times
![複数の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](https://image.slidesharecdn.com/webapthegoodpartsp-150304184140-conversion-gate01/85/Web-API-The-Good-Parts-13-320.jpg)
Uploaded byAPI Meetup
Web API: The Good Parts 落穂ひろい
API Meetup Tokyo #6での水野さんの講演資料です。ご本人から許可をいただいて掲載しています
More Related Content
![[AWS EXpert Online for JAWS-UG 18] 見せてやるよ、Step Functions の本気ってやつをな](https://cdn.slidesharecdn.com/ss_thumbnails/awsxon18howfarstepfunctionsgo-211124111849-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Web API: The Good Parts 落穂ひろい
Web API: The Good Parts 落穂ひろい
- 1. Web API: TheGood Parts 落穂ひろい 水野貴明 @mizuno_takaaki
- 2. 本日のお話 • APIリクエストの回数を減らす • 非同期API •SSKDs向けAPIとAPIバレ • クライアントサイドとサーバサイドの役割分担
- 3.
- 4.
- 5.
- 6. 本書を書くにあたって • コードを載せない – コードを載せると分厚くなるし、特定の言語に寄って しまう –コードを載せるとAPIそのものの設計とは違うところに 目が言ってしまう危険性がある • 言葉の細かい定義よりも使いやすさを – RESTとはなにか、など • 決定的な選択肢がない場合でも、自分なりの意 見を述べる – The Good Partsシリーズを名乗る上での挟持
- 7.
- 8. 使いやすいとは • 意味がわかりやすい • 一貫性がある •標準（デファクト・スタンダード含む）にそって いる（ので類推がきく） • クライアントが処理しやすい • テストがしやすい • ドキュメントがわかりやすい
- 9.
- 10.
- 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.
- 15. 非同期なAPIとは • リクエスト時に直ぐに結果が返らず、クライア ントのリクエストした処理が完了するのにはそ の後しばらく時間がかかる • JobQueueシステムへのインターフェイス • コールされてから結果を返すまでの処理が重 いケースに用いられる – 課金処理 – データ集計処理
- 16.
- 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.
- 21. APIは隠してもバレる • 自分たちのウェブサイト/アプリのためにAPIを 作りたい • 一般には公開しない •でもサービスがメジャーになると、簡単にバレ て解析される
- 22.
- 23.
- 24. APIは隠してもバレる • したがって一般公開しないAPI (いわゆる SSKDs 向け API) でもネット上に公開している 場合はセキュリティなどの問題はきちんと気 をつける
- 25. ちょっと違った事例 Twitter公式クライアントのコンシューマキー • Twitterの公式クライアント(iPhoneやAndroid など)のコンシューマーキーを解析して公開し た人がいた • このコンシューマーキーでアクセスすると、 RateLimitが若干ゆるかった • フリーミアムやユーザーの支払額に寄ってリ ミットの量を変更している場合はこうしたリス クもありうることを念頭に置く
- 26.
- 27.
- 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をこう叩いて欲しい、こう叩きたいと いう思想を一致させるためにはネットワーク の両側を同じ開発者が担当するのもひとつの 解