20170420 infoteria apiセミナーupload

APIエコノミーに欠かせない
「API を作る」ことの重要性
2017/04/20
CData Software Japan

See the World as a Database
Agenda
• About CData Software
• Why need your APIs?
• API 開発のエレメント
• 使いやすいAPI
技術屋なのでビジネス的に「このデータ
を公開すれば儲かります」という話では
ありません。あしからず。

Speaker
桑島義行
• CData Software Japan 合同会社技術担当ディレクター
• Japan Web API Community の事務局 https://jwacom.connpass.com/
専門
• データベーステクノロジー
• ビジネスアナリティクス
• データマネジメント
• APIマネジメント
Twitter : @kuwazzy
Facebook : Yoshiyuki.Kuwajima
SlideShare : http://www.slideshare.net/cdatajapan
Qiita : http://qiita.com/kuwazzy
Codezine : https://codezine.jp/author/1671

• 20年以上にわたりデータ関連
コンポーネントを提供
• 80+ 対応データソース
• 「See the World as a Database」を
ミッションにクラウドデータ
への接続方法を標準化
About
• CData Software, Inc.
• Started: 1994 (/nsoftware)
• Location: Chapel Hill, NC
• a spin-off of /n software
• CData Japan: 2016/6
(JV with Infoteria)

: RDB(SQL) ⇔Web API 変換のエキスパート
Data Drivers
Web API を標準SQL
で利用可能に
JDBC/ODBC/ADO etc.
API Server
RDB/NoSQL/file から
超高速でREST API
を自動生成

API とは？
•Application Programming Interface
•ソフトウェア同士が互いにやり取りするインターフェース

増加するPublic API & さらに多いPrivate API
Private APIs が遥かに多い
• モバイルバックエンド
• クラウド⇔オンプレ間
• マイクロサービス
• パートナーAPI
• 特定顧客へのAPI など
Public APIs
• Saas API
• Web Service API
• Paas/Iaas API
• 既に2万を超えるAPI が
存在し、急速に増加中
引用元 : https://www.programmableweb.com/api-research

API 公開の必要性を考える
•ユーザー目線
•パートナー目線
•ビジネス拡大
•（競合がすでにAPI を公開しているから）

ユーザー目線①ウェブサービスの限界
•ウェブサービスのユーザーは目でデータを取得して、次の処理を指示
•結局はコピペであって、オートメーションではない
情報取得
処理
コピペ

ユーザー目線②デバイス多様化
•ブラウザ+iOS+Android 向けに異なるバックエンドを開発？
•統一されたAPI を作って開発および管理コストを下げるべき

ユーザー目線③UI を決めるのは誰？
•サービスへの顧客アクセスにはUI が必要
•ブラウザを好むユーザーもいれば、モバイルアプリを好むユーザーも
いるし、チャットしか使わない人も⇒複数のUI に自社対応は苦しい
同じタスク
異なるUI

ユーザー目線④他のサービスへの統合
•機能ごとに他のサービスやアプリを使うことは負担
•LINEなどよく利用されている他サービスからでも自社サービスを使えれば便利

ユーザー目線⑤サービス間の比較
•たくさんあるものから最適なものを選ぶには比較が必要
•時間やコストをかけずに比較

パートナー目線①継続性・安定性
•APIとして提供を始めると可用性・継続性・互換性が向上
•アドホック対応でこれらを満たせない
「24/365？」「バージョンは？」「デバイスは？」

パートナー目線②エコシステムへの参入が容易
•参入が簡単な例：
「やってみようかな」→すぐに公開されたAPI ドキュ
メントチェック→エンドポイント一つを動かしてみ
る
•参入が難しい例：
「やってみようかな」→サービス提供元に連絡→利
用目的チェック→紙のパートナー契約→個別の方法
でのデータ連携確立→研修が必要

パートナー目線③セキュリティの確保
•「ID とパスワードを下さい。スクレイピングします」
⇒セキュリティ上推奨されない
•モダンな認証(OAuth)、レートリミット、ログ管理は必須

ビジネスの拡大①モノ→コト
•ハードでの差別化ではなく、サービスや体験が差別化要因に
•サービス化が起これば、サービスを拡大させるためにAPI が必要に

ビジネスの拡大②データ資産の活用
•自社サービスの利用データを活用
‧検索
‧利用ログ
‧レコメンド
‧GPS
‧アクセス
‧グラフ

ビジネスの拡大③ オープンイノベーション
•非コア機能の他のサービスからの補完
•サービスインのスピード化
•逆に他者/他社に自社のサービスを使ってもらえればユーザーは
飛躍的に拡大
決済メール送信地図検索ファイル・
簡易DB
電話

「競合がすでにAPI を公開しています」

まとめ：API が必要な理由
•ユーザーの満足度を上げる
•管理コストを下げる
•パートナーの参入を容易にする
•セキュリティを確保する
•ビジネス転換の道具
•競争優位
•ユーザー増加
•コスト最適化
•パートナー経済圏確立
•リスク管理
•収益増加
どこに自社として重点を置くかの判断が先にあるべき

後半の結論を先に…
•API の開発は多くの要素があり、スクラッチでの開発には相当の
知識とリソースが必要
•API を使ってもらう為には、使われやすいAPI の提供が必要
•上記2点を解決するには、API 管理ツールの利用が効果的

API 開発のエレメントは多い & 標準の変化が速い
•バックエンドのデータソース(RDB/NoSQL/Saas) とAPI公開サーバーの接続
•エンドポイントの設計
•利用できるHTTP メソッドやスクリプトの定義
•メタデータの扱い
•データ形式の決定（通常複数）
•デプロイ
•ユーザー認証
•IP 制御
•リミット制御
•課金
•通知設定
•ログ提供
•API ドキュメント作成・管理
•管理コンソール
……. And more
設計
スキーマ・メ
ソッド定義
出力定義
ユーザー管
理
利用支援
バージョン
管理
標準対応

設計
•公開するエンドポイントを設計
•REST ? それとも?
•「だれが、何のために使うのか？」に従う
設計
スキーマ・メ
ソッド定義
出力定義
ユーザー管
理
利用支援
バージョン
管理
標準対応

接続・
メソッド定義
•元となるデータソース（ RDB/NoSQL/Saas ）との接続
•スキーマ定義
•HTTP メソッド定義
設計
スキーマ・メ
ソッド定義
出力定義
ユーザー管
理
利用支援
バージョン
管理
標準対応

出力定義設計
スキーマ・メ
ソッド定義
出力定義
ユーザー管
理
利用支援
バージョン
管理
標準対応

ユーザー
管理
•ユーザー認証
•IP 制限
•リミット
•課金
•SSO
設計
スキーマ・メ
ソッド定義
出力定義
ユーザー管
理
利用支援
バージョン
管理
標準対応

利用支援
•ドキュメント
•Swagger による標準記述
•管理コンソール
•ログ
•通知
設計
スキーマ・メ
ソッド定義
出力定義
ユーザー管
理
利用支援
バージョン
管理
標準対応

デモ
CData API Server で基本的なAPI 開発エレメントを見てみましょう
設計
スキーマ・メ
ソッド定義
出力定義
ユーザー管
理
利用支援
バージョン
管理
標準対応

さあ、API エコノミーだ！
API 作った！
「公開」ポチッ
。。。あれ？
あまり、利用が増えない

API 利用者の悩み
•対応したいAPI が多すぎて、手に負えない
•ドキュメントが難解、API毎に記述されている内容が異なる
•オフショア開発なんだけどドキュメント英語版ないの？
•RDBMS/SQL ほどにAPI を扱えるエンジニアが少ない
•既存ツールがRDB/SQL 対応で、JSON 対応ではない
•API 仕様の変更が多すぎて管理できない
•API の記述方法などの規格化が進んでいない

どうすれば使ってもらえる？--後悔しないために
•明確な目的と利用例
•業界標準への準拠
•ツールやパートナー
⇒API 管理ツールを使う理由を考えてみるきっかけに

後悔しないために①明確な目的と利用例
•とはいえ、最初から明確にすることは不可能・コスト高い
•「API ないんですか？」とはじめに言ってくれたユーザーやパー
トナーと利用シナリオを明確化
•作り込む前に動くデモを
•まずはPartner API で一般公開ではなくても
デモAPI Partner API Public API
⇒API Gateway、API 管理ツールでAPI を高速開発。

後悔しないために②業界標準への対応
•さまざまな業界標準
‧OData （まだまだ実質の標準）
‧OpenAPI （Swagger）
•なぜ業界標準が重要
‧エンジニアは業界標準に準拠してもらうと楽
‧ETL などのツール側でも業界標準を意識
⇒API 管理ツールでAPI は業界標準準拠。
新しい標準への対応もツールが実施。

OData
• Microsoftが主導となり推進しているプロトコル
• HTTPメソッド（GET/POST/PUT/DELETE）でデータの参照更新ができ
る仕様
• RESTfulな設計パターンを実装
• ODataデータソース
 Power BI
 Tableau
 Salesforce（Lightning Connect）
：
• ODataエンドポイントを作成
 Visual Studio (ASP.NET Web API)
 Apache Olingo / Odata4j（JavaのOData Framework）
 CData API Server / OData Connector
 DynamicsCRMではWCFのData Servicesフレームワークに基づいて実装
（ https://msdn.microsoft.com/ja-jp/library/gg334279(v=crm.7).aspx ）
http://www.odata.org/

Open API (Swagger)
http://swagger.io/
• REST APIの記述に関する仕様と、APIをコールするためのコードとド
キュメントを自動生成するツール群
• Apache 2.0 License
• 2015年に推進団体「Open API Initiative」が設立
 The Linux Foundationの協力のもと、Microsoft, Google , IBM , Paypal, 3Scale(Redhat) , Apigee(Google) などに
より結成
https://www.openapis.org/

後悔しないために③ツールやパートナー
パートナーやツール連携なしにAPI エコノミーは作りづらい
•代表的なパートナーとの1 to 1 連携（連携サービス化）
•代表的なツールETL、BI、開発ツールとの連携
‧ETL（ASTERIA WARP ほか）
‧BI
‧Point-to-point ツール（Zapier、IFTTT、Micrsoft Flow etc）
•ODBC Driver、JDBC Driver の提供
•SDK の提供
⇒API 管理ツール選定のポイントにも

Conclusion
•モバイル、ウェブサービス時代にAPI の公開は必須
•API の開発は複雑
•利用促進には、業界標準への準拠やAPI 内包ツール、パートナー
圏の拡大も重要
•API 管理ツールの利用は上記の解決策となり得る

Contact
CData Software Japan 合同会社
Email: sales@cdata.co.jp | Tel: 050-5578-7390

20170420 infoteria apiセミナーupload

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Ähnlich wie 20170420 infoteria apiセミナーupload

Ähnlich wie 20170420 infoteria apiセミナーupload (20)

Mehr von CData Software Japan

Mehr von CData Software Japan (20)

20170420 infoteria apiセミナーupload