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