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