セッション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

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日) 時点のものであり、予告なく変更される場合があります。
本コンテンツの著作権、および本コンテンツ中に出てくる商標権、団体名、ロゴ、製品、サービスなどはそれぞれ、各権利保有者に帰属します。