こんにちは！
APIStudy運営事務局の對馬です。
去る7月25日に株式会社オージス総研さんにて、APIStudy#10が開催されましたので、その様子をご報告します。
前回#9の開催報告はこちらからご覧ください。
第1部：LTタイム
まずはLTタイムから。
今回も2名の方にLTを発表していただきました！
齋藤さん
API管理サービス/製品とはなんぞや ＆ 事例で説明Amazon API Gateway (without Lambda) 利用のポイント
API管理サービスについて
提供される機能：
- APIに共通的に必要な機能
- 管理機能
- API管理者ポータル
目的：
- 効率的にAPIの開発や運用、APIクライアント側の開発を行いたい。
- 外部の利用者に公開して使ってもらいたい→セキュリティやポータルを作りたい。
API管理サービスは種類も様々で、クラウドサービス、製品、オープンソースソフトウェアなどがあり、ケースに応じて適切なものを選択することができます。
Amazon API Gateway
Amazon API Gateway を活用した、複数の事例を紹介していただきました。
API Gateway 採用の目的
- APIの認証認可を内部APIの実装から分離
- APIのユーザ、クライアント、トークンの管理のサービスを連携
- APIの流量制御
- 効率的な支払モデル
ハイブリッド構成における役割
- API Gateway：APIクライアントの認証、流量制御
- APIサーバ(内部API)：HTTPリクエスト/レスポンスのハンドリング、HTTPリクエストのバリデーション、DBアクセス、エラーハンドリング
そして流量制御の紹介です。
恥ずかしながら對馬はこの単語を知らなかったのですが、下の図がとてもわかりやすかったです！
Amazon API Gatewayは、このトークンバケットアルゴリズムに基づいて流量を制御しています。
現在、国がWeb APIを活用させようとする動きがあるため、この5月・6月あたりから企業がざわついているそうです。
今までWeb APIに関わりがなかった企業もAPIを意識し始めたため、API Gateway などAPI管理・運用をサポートする製品やサービスが今、注目され始めていると話されていました。
もっと進化するかもしれないAPI関連の製品・サービスを、これからもチェックし続けていきたいですね。
芹沢さん
APIStudyにて2回目の登壇です！
前回のLTはこちら、#4にてファイルアップロードについての発表していただきました。
今回は『WebAPIのScopeについて』です。
認証・認可
認証(Authentication)：相手が誰であるか確認すること。
例）銀行カードは運転免許証・印鑑がないと再発行できない
認可(Authorization)：条件に応じたリソースのアクセス権限を付与すること。
例）定期券は本人でなくても利用できる
Scopeについて
Scope：アプリケーションに対するAPI許可範囲
有名企業がどんなScopeを持っているのか、比較しました！
6つの企業を比較したが、意外とどれもバラバラでScopeのベストプラクティスは見出せなかったようです。
そこで、ベストプラクティスをググりました！
(検索したいこと)＋Best practiceとググると意外にヒットするという新情報です。
今回ヒットしたベストプラクティスがこちら。
- リソースを置く(user等)
- ’:’(コロン)+ 限定したい機能を指定(emails等)
- ’:’(コロン) + read/write
実践的なScope。
- リソースがネストしている場合はコロン’:’で連結。
- 使いやすいのが1番！Scope名とリソース名は一致させた方がいい。API利用者がリソース名からScopeをある程度連想できると親切かも。
- ScopeもUX大事。
- 名づけは、拡張性に影響が出やすいので要注意。
- 運用者・利用者どちらにも親切にするべき！
第2部：ディスカッションタイム
では、ディスカッションを始めていきます。
今回は2チームに分かれ、テーマを深堀していきました。
- API Gateway
- OAuthのScope
もくもく…
なぜか全員立っているゲートウェイチーム。
そしておもむろに移動を始めるゲートウェイチーム(奥)と不動のOAuthチーム(手前)
チームそれぞれのやり方が目立っていて、面白みを感じました。
共有タイム
API Gateway
採用しないケースを考えました。
- レーテンシーが究極に求められるとき。
- ReadOnly など認証が必要ないとき。
その他API Gatewayを比較しました。
IBM：オンプレが提供されている。クローズドなAPIを作りたいとき
AWS：S3、Lambdaなど、AWSのサービスを使っているなら選びやすいかも。この点はAzureも同様。
Azure：管理画面がイケてる。(個人的感想)
AWSで見つけた機能。
クライアントライブラリを作ってくれる機能がありました。
APIを乗っければ勝手にクライアントライブラリを作ってくれて、取得、ユーザーに配布すれば簡単にHTTPコールできるので、エンドユーザーにも優しいです。
OAuth
Scopeについて
細かくするのと細かくなったのをラップするのが両方あることが理想。
コロンつけてくのが現在のプラクティスだが、細かい要求に対応するにはScopeを細かくしていく必要があります。しかし、細かくしすぎると今度は使う側が大変になってしまうので、ある程度の大きさで扱えることがベストです。
認証認可まわりでキーワード調べました。
認証と認可はセンシティブなので、自前で管理するとつらいです。
外部にサービスがあるならそれがいいのでは、ということで調べたところOAuthをやってくれるSaaSがあるそうです。
それがAuthlete ！無料プランもあります。
また、Authlete の共同設立者 TakahiroKawasaki 氏は、 Qiitaとかに認証回りの記事を書いており、とても詳しいないようなのでぜひ参考にしていきましょう。→Qiita： http://qiita.com/TakahikoKawasaki
http://oauth.jp/というブログもなかなかの詳しさと高頻度で更新されるのでこちらもあわせてチェックをお勧めします。
おわりに
今回はディスカッションチーム数が、いつもより少ない2チームとなり大人数のチームが作成されました。
大人数だと発言が難しくなってしまう課題がありますが、今回はたくさんの意見を交換ができたので結果オーライかな、と思いました。
そして！今回のグラレコはこちら！
今回もすごいですね！
いつもありがとうございます！
そして！
次回開催が決定しています！
#11は、7/10にオープンしたばかりのコワーキングスペース『POINT EDGE ShibuyaBASE』にお邪魔します！
もうお申込みいただいている方も多いかと思います。
まだ空きがございますので、ぜひ周囲の方を誘って遊びに来てください！