#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ

セッションID：MW04

セッションタイトル：誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しい API エコシステム活用アプローチ

日時：DAY2 ( 5 月 30 日 )　16:10 - 17:00

部屋：Room G

URL：https://www.microsoft.com/ja-jp/events/decode/2019session/detail.aspx?sid=MW04&kw=API

皆さん、Web API 使っていますか? 世界の API 管理市場は 2022 年までに現在の 2 倍 (3,000 億円) の市場規模になると予想されていて、今まで以上に API を使ったマッシュ アップは重要性を増すようです。

しかしながら、一口に API と言っても、GraphQL や OpenAPI (Swagger) といった各 API スタイルが成熟してきて、単純に REST という切り口だけでは収まらなくなってきました。また、その API のユースケースも、単純に開発者がマッシュ アップするだけでなく、Power BI や Azure Logic Apps といったサービスからエンド ユーザーが使ったりと、多様化が進んでいます。

そんな多様化され、今後ますます重要性が増す Web API は何を意識して開発するべきなのか? 昨今のメジャーな API スタイル (REST・GraphQL・OpenAPI・OData) と認証・認可 (OAuth) の仕組みに焦点を当てながら、Azure デベロッパーにとってもエンド ユーザーにとっても嬉しい「API エコシステムのあり方」についてお伝えします。

Session Info：https://gist.github.com/sugimomoto/930d33ee469e7e8afdb1925fd854261a

Transcript

1. Ask the Speaker 写真撮影 動画撮影 セッション資料 後日公開 Twitter ハッシュタグ MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しい API エコシステム活用アプローチ CData Software Japan 合同会社 Lead Engineer 杉本 和也 #decode19 #MW04 http://bit.ly/decode2019MW04
2. de:code 2019 MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しい API エコシステム活用アプローチ CData Software Japan 合同会社 Lead Engineer 杉本 和也
3. Profile CData Software Japan 合同会社 Lead Engineer 杉本 和也 製品開発・サポートを担当するリードエンジニアとしてCData Software Japanで活動中。 Web API がリリースされるたびに検証してみる Web API Holic。 最近の個人的トピックはAPIエコシステムのあり方とポストREST API の可能性がある新しいAPIプロトコルのウォッチ。 面白いWeb APIがあったらTwitterで教えてください。
4. About CData Software
5. Question 1
6. みなさんはAPIを「提供（Provider）」している方々ですか？ それともAPIを「利用（User）」する方々ですか？
7. 世界のAPI Management 市場は2022年までに 現在の2倍（3,000億円）の市場規模 API Management Market Augmenting Rapidly To Reach USD 3,436.16 Million by 2022 https://www.zionmarketresearch.com/news/api-management-market
8. https://gmo-aozora.com/news/2019/20190115-01.html オープンAPIの無償提供 / GMOあおぞらネット銀行
9. https://minikura-plus.com/ APIリクエストで実際に物流が動く / minikura
10. https://justincase.jp/api/ 保険の申し込みをAPIで組み込み / justInCase
12. https://tech.nikkeibp.co.jp/atcl/nxt/news/18/03240/ 「すべての企業がソフトウエア会社に」 マイクロソフトのナデラCEOが語る
13. 近い将来すべての企業・ユーザーが 「API Provider」であり「API User」になる可能性がある
14. Question 2
15. 誰のためのAPI ?
16. その API のユーザーは誰ですか？ デベロッパー？ パワーユーザー？ エンドユーザー？ 社員？ パートナー？ カスタマー？ 取引先？
17. 全員！
18. APIのユーザーは誰ですか？ https://www.getpostman.com/
19. APIのユーザーは誰ですか？ https://dynamics.microsoft.com/ja-jp/microsoft-power-platform/
20. APIのユーザーは誰ですか？ https://togetter.com/
21. 近い将来すべての企業・ユーザーが 「API Provider」であり「API User」になる可能性がある
23. APIを取り巻く現状と課題 ・増加するクラウドサービス ・様々なAPIユーザーの出現 ・企業内外のAPIの増加 ・ユースケース・シチュエーション・シナリオの増大
24. そこで重要になるのが API Ecosystem を意識した API の提供
25. API Ecosystem?
26. Web API External Service 3rd Party Tool SDK Protocol Style REST・SOAP OData・GraphQL gRPC etc... 各言語ごと Java・C#・PHP Python etc... ETL/BI Tool 帳票・アプリビルダー etc... IFTTT MS Flow etc... Web API の周辺に存在し Developer Experience に付与する環境 Portal Community ドキュメント フォーラム・Blog etc 開発者コミュニティ パートナーシップ
27. 私達は様々なツールやサービスを介して APIとつながっている 「APIを作る？ 公開する？」だけではなく 「どうしたら組み合わせて利用してもらえる か？」が重要
28. でも、API Ecosystem は難しい
29. Portal Community Web API External Service 3rd Party Tool SDK Protocol Style
30. そこで 「Azure API Management」 「Web API Standard」を 活用しよう！
31. このセッションのゴール みなさんが提供している、これから提供する API が 「より使われる・より活用される API になるために」 「強固な API Ecosytem を築くために」 そのために活用できる
32. Azure API Management for DX
33. What’s Azure API Management?
34. Client Web API What’s Azure API Management? Azure API Management User Web API Web API API Management のベースになる考えは API を「作りやすく、提供しやすく、運用しやすく
35. Azure API Management で実現する DX
37. http://kageura.hatenadiary.jp/entry/apikpi
38. Hello World
40. 開発者ポータル Azure API Management が標準で提供するAPI利用ユーザー向けポータルサイト ・API のドキュメントの閲覧 ・対話型コンソールを使用して API のトライアル ・API キーを取得するために、アカウントを作成してサブスクライブ ・自分自身のAPI使用状況に関する分析 ・Blog・問い合わせフォームの利用 https://docs.microsoft.com/ja-jp/azure/api-management/api- management-customize-styles
43. 認証 Azure API Management がAPI保護の観点で提供する認証は3種類 ・Subscription Keyによる認証 ・OAuth AccessToken と jwt-validation を組み合わせた外部IdPによる認証 ・クライアント証明書を使った認証 注意：Azure API Managementそのものは IdP のための機能は提供していない。 HTTP Requestで渡ってきたTokenを検証する仕組み（jwt-validation）が提供さ れている。
46. DXのために考えたい。なぜ OAuth を選択する？ 管理者・デーモンだけが使うようなAPIユースケースを想定したい →Subscription 方式でも十分ではないか ※Azure API Management標準機能でサポートできる Azure AD に登録されているユーザー・パートナーに向けて公開したい →Azure AD（もしくは他社 IdP）基盤で提供 ※Azure API Management の jwt-validationでサポート サービスのエンドユーザーもそのエンドユーザーのスコープでアクセスしたい →OAuthを採用する価値あり ※別途 IdP を用意し、 jwt-validationと組み合わせる
47. Protocol変換 ・SOAP API から REST API に変換してユーザーに提供することが可能 ・すでに内部でSOAPのマイクロサービスを使用していて公開する場合等に ・単純にSOAP APIのパラメータをPOSTで受け取るエンドポイントになる ・APIのExperienceを統一するために活用 SOAP API のインポートと REST への変換 https://docs.microsoft.com/ja-jp/azure/api- management/restify-soap-api
49. Azure API Management for DX まとめ ・ユーザーがAPIと接触する際の Experience を大きく向上させることができる ・デファクトスタンダートの認証機能を簡単に追加することができる ・プロトコル変換・JSON-XML変換などでユーザーの利用敷居を下げる
50. Web API Standard for DX
51. What’s Web API Standard? OData, Swagger, GraphQL, gRPC, SOAP, etc
52. ちょっと考えたい「APIの標準」ってなんだろう？ そもそもなぜ「API で繋ぐこと」に苦労するのか？
53. そこで、改めて REST ってなんだっけ？ ソフトウェアアーキテクチャのスタイルのひとつ
54. Web API を REST たらしめる“原則“（≠規約）
55. 規約・プロトコルでは無いから REST は REST 故に簡単には繋がれない プログラム / サービスが 動的に REST を理解することはできない
56. では、なぜ API Standard? API Standard に則ることで それらが持っている「Ecosystem」を活用できる 今回はSwaggerとODataの「Ecosystem」を見る
58. Swagger (OpenAPI) って何？ OpenAPI Specification（OAS）は、ソー スコードへのアクセス、追加ドキュメント、また はネットワークトラフィックの検査を必要とせず に、人間とコンピュータの両方がサービスの機 能を発見して理解することを可能にする、 プログラミング言語に依存しないREST APIの 標準的なインターフェイス記述を定義します。 引用元： https://github.com/OAI/OpenAPI- Specification
59. Swagger (OpenAPI) って何？
60. Swagger (OpenAPI) で公開しているAPI SendGrid https://github.com/sendg rid/sendgrid-oai CloudSign https://app.swaggerhub.c om/apis/CloudSign/cloud sign-web_api/0.8.0 SmartHR https://developer.smarthr. jp/api/index.html
62. Use Case .NET Framework C# / Swagger
64. Use Case Azure LogicApps / Swagger
65. 普通にHTTPコネクタを使う場合
66. Swagger Specを使う場合
67. Swagger Ecosytem のポイント ・各言語ごとのSDKをSwagger Specから自動生成 ・LogicApps / MS Flow で Swagger Specを読み込んでさくっと連携 ・もちろん Document としての見やすさ・テストのしやすさもGOOD
69. OData って何？ ODataは、データモデルの記述、およびそれらのモデルに従ったデータの編集および照会を サポートするプロトコル。 ・ メタデータ：特定のデータプロバイダによって公開されるデータモデルの機械可読の記述。 ・ データ：データエンティティのセットとそれらの間の関係。 ・ クエリー：サービスがフィルタリングとデータへの変換を実行するよう要求し、結果を返す。 ・ 編集：データの作成、更新、および削除。 ・ 操作：カスタムロジックの呼び出し ・ ボキャブラリ：カスタムセマンティクスの付加
70. OData のポイント その1 Query Support URL Components
71. OData のポイント その2 Metadata Endpoint のサポート
72. OData で公開されている API Dynamics 365 https://dynamics.micro soft.com/ja-jp/ Salesforce https://www.salesforce. com/jp/ SAP HANA https://www.sap.com/j apan/products/hana.ht ml
73. Use Case Power BI / OData
74. ユースケース：Power BI: OData
75. Use Case Azure Data Factory / OData
76. ユースケース：Azure Data Factory : OData
77. Use Case Dynamics 365 / OData
78. Use Case Dynamics 365 / OData
79. OData Ecosystem のポイント ・Metadata・クエリアプローチが確立されているため、ツールからの接続しや すさはピカイチ。 ・Microsoft Ecosystem にもめちゃくちゃアドバンテージがある。 ・スクラッチで作るのはちょっと大変だが、.NETベースのライブラリやOData API 自動生成ツールと組み合わせて構成することで、かなりやりやすくなる。
80. まとめ
81. 近い将来すべての企業・ユーザーが 「API Provider」であり「API User」になる可能性がある
82. API Provider にとっても API User にとっても嬉しい Azure API Management for Developer Experience DX の観点でこれらの要素を見ることで より使ってもらいやすい・より使いこなされる API 提供に繋げることができる
83. API Provider にとっても API User にとっても嬉しい Web API Standard for Developer Experience API Standard が持つ既存のエコシステムを活用す ることで、自分たちが提供する Web API にもその 力を加えることができる
84. リリースだけされたAPIに価値は無い 使ってもらえる・活用される環境「APIエコシステム」 を整えて、 よりユーザーに親しまれるAPIへ！ Thanks!
85. Reference http://bit.ly/decode2019MW04
86. © 2018 Microsoft Corporation. All rights reserved. 本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。 © 2019 Microsoft Corporation. All rights reserved. 本情報の内容 (添付文書、リンク先などを含む) は、de:code 2019 開催日 (2019年5月29~30日) 時点のものであり、予告なく変更される場合があります。 本コンテンツの著作権、および本コンテンツ中に出てくる商標権、団体名、ロゴ、製品、サービスなどはそれぞれ、各権利保有者に帰属します。