API戦略とアーキテクチャ: 調和のとれたアプローチ

22

API（アプリケーション・プログラミング・インタフェース）の隆盛は、ビジネス・チャンスと技術的な課題の両方をもたらします。ビジネス・リーダーにとって、APIは新しい収入源を開拓し、顧客の価値を最大化するチャンスです。しかし、エンタープライズ・アーキテクトは、バックエンド・システムを新しいWebアプリケーションとモバイル・アプリケーションで再利用できるようにするAPIを構築しなければなりません。

すべての利害関係者は、APIプログラムのビジネス目標と技術上の課題が密接な関係にあることを理解する必要があります。また、プログラム・マネージャは実際にインタフェースを構築するアーキテクトに対し、提案したAPIの重要なビジネス目標を明確に伝えます。

一方、アーキテクトはAPIのインフラストラクチャをデプロイし、インタフェースを設計するプロセス全体を通して、これらの目標に焦点を合わせます。技術的な意思決定はすべて、エンドユーザにとって価値あるクライアント・アプリケーションを構築する開発者の作業に役立つインタフェースの作成を視野に入れる必要があります。

このeBookでは、APIプログラムの成功の基盤となる結果重視のAPIを設計するためのベスト・プラクティスについて説明します。

はじめに

21世紀のエンタープライズITは、それまでサイロ化していたデータベースとアプリケーションを横断的に利用することが特徴ですが、それによって組織の境界を超えたデータと機能へのアクセス、または新しいシステムでの再利用が可能になります。このトレンドはサービス指向アーキテクチャ（SOA）によって初めて出現しましたが、最近では、Web指向のAPIが圧倒的に増えています。

あるレベルでは、SOAを中心とした「Webサービス」はWeb APIと同じです。いずれもバックエンド・システムを提供するためのインタフェースです。ただし、2つの技術には根本的な相違があり、それらが基本的な設計の決定に大きく影響しています。

3

第1部: SOAからAPIへ

図1: SOA対API

統合の目標

プロジェクトの 対象

インタフェースのユーザ

社内または 対パートナー

ITコスト

エンタープライズ・ アーキテクト

外部、 主に対顧客

事業収益

アプリケーション 開発者

SOA API

$$$

• 技術的な主な相違は、SOAプログラムが社内のサーバとサーバの統合を簡略化するためのWebサービス開発が中心であるのに対し、Web APIはWebとモバイルベースのアプリケーション開発を迅速化することを目的とし、多くの場合、顧客に使用されることです。

• SOPプログラムは一般的にIT部門が担当し、コスト削減を重視するのに対し、APIプログラムはビジネス開発組織が新しい収入源の創出を目的に計画します。

• 多くのSOAプロジェクトはエンタープライズ・アーキテクトが異種混合システムの統合を簡略化し、新しいITサービスを提供するために自ら策定します。それに対し、APIプログラムはアプリケーション開発者のニーズに対応することを重視します。

4

API設計の目標

第1部: SOAからAPIへ

このように相違はあるものの、多くのAPIプログラムは過去のSOAイニシアチブから派生しています。社内またはパートナーを統合するWebサービスは、社内外の開発者にも提供されています。そのプロセスでは、会社がWebサービスを通してIT資産を最初に公開したAPIプログラムとは、ドライバも要件もまったく異っていることをAPI設計者は覚えておく必要があります。

これを念頭に、API設計の幅広い目標は一般的に以下のように定義できます。

• アプリケーション開発者とアプリケーション・ユーザの両方に対するセルフサービスの提供

• 価値ある企業のリソースへのアクセスの障壁の減少

• クライアント・アプリケーション開発者のニーズと好みの優先順位付け

• 社内外のリソース間のコラボレーションの奨励

• IT資産を開かれた市場に提供するためのセキュリティと拡張の問題への対応

上記に加えて、APIの設計ではインタフェースのビジネス価値を最大化することに集中する必要があります。第2部では、APIによってビジネスにどのように付加価値が得られるかを詳細に説明します。

第2部: APIのビジネス・バリューチェーン

5

APIには本来、価値はないかもしれませんが、ビジネスには多くの価値をもたらします。その価値は、そのインタフェースが可能にするバックエンド・データとアプリケーションの機能を通して提供されます。このような観点では、APIは単純に、組織にとって大きな価値のあるシステムを直接的なビジネス価値の創出が見込まれるアプリケーションで再使用することを簡略化するものです。

このような考え方は便利ですが、より詳細に観察すると、設計の優れたAPIは、実際には複雑で強力なコネクタの役割を担います。つまり、ITシステム、社内外の人材、クライアント・アプリケーション、顧客など、多様なビジネス資産を接続し、これらの資産の潜在的な価値をよ

り効果的に顕在化します。このような状態を当社では、「APIのバリュー・チェーン」と呼んでいます。

APIでは、この比較的複雑な方法で価値が提供されることを理解していないと、APIは技術的な効率性ではなく、ビジネス価値を提供するために存在するという事実を簡単に見失ってしまいます。また、APIが価値を提供する方法はSOAよりも直接的ですが、実際にセールス・リードや売り上げを提供するブラウザベースのWebサイトほどではありません。APIでは、以下で説明するように、多様な資産を接続するという微妙な方法で利益が創出されます。

図2: APIのビジネス・バリューチェーン

バックエンド・システム APIプロバイダ アプリケーション開発者 クライアント・アプリケーション エンドユーザ

APIによる価値創出の例 APIアプリケーションにはそれぞれ独自の価値があります。企業はAPIを主に、以下の目的で使用できます。

新しい収益を直接創出開発者のアクセスに対する課金、インタフェースを使用した課金制アプリケーションの社内開発、Eコマースなどに利用すれば、APIは直接的な収入源になります。

顧客リーチと価値の拡大 APIでは、既存のサービスを新しいプラットフォームとデバイス経由で提供することで、新規顧客へのリーチのプロセス、または現在の顧客の価値の増加が簡略化されます。

セールスおよびマーケティング活動のサポート APIではオンライン・マーケティングのベスト・プラクティスである没入型機能の開発が可能になるため、エンゲージメントが向上し、製品とサービスの販売が強化されます。

ビジネスおよび技術変革のシミュレーション APIではバックエンド・システムを変更せずにアイデアを実行できるため、変革の障壁が大幅に解消され、新しいシステム、製品および戦略の開発が促進されます。

6

第2部: APIのビジネス・バリューチェーン

7

• どのようなシステムが脅威の標的となり、どのような場所（どのようなユーザのいる場所）に脅威は存在するか。

• どのような開発者が対象となり、その開発者はどのようなアプリケーションを開発しているか。

「対象となるのはどのような開発者であるか」は特に重要な質問ですが、これは、APIを分類する最も基本的な方法、つまり、「プライベート」か「オープン」であるかに相当します。プライベートAPIは社内でのみの使用、または、場合によってはパートナー企業による使用を目的としています。オープンAPIはより幅広い外部の開発者コミュニティに提供され、これらの開発者は企業のバックエンド・リソースを無料で活用して独自のアプリケーションを開発します。

プライベートAPIは、Webサービスの考え方に近い存在です。プライベートAPIは一般的に、社内の開発者、契約業者またはパートナーが社内外のアプリケーションを効率的に開発できるようにすることを目標にしています。APIでは新しいアプリケーションを優れたコスト・パフォーマンスで開発できるようになるため、多くの場合、Webサービスと同様にコスト削減が重視されます。しかし、多くのプライベートAPIは、新しいビジネス価値がより直接的に創出される一般ユーザ向けのWebおよびモバイル・アプリケーションの開発に使用されます。

オープンAPIのプログラムはユーザの採用率を重視する傾向があります。サードパーティの開発者にAPIへのアクセスを提供することで、企業はそのIT資産の潜在的な顧客ベースの最大化を図っています。そのため、開発者の採用率はオープンAPIの成功を評価する重要な測定基準になっています。オープンAPIは数量的にはプライベートAPIを下回りますが、オープンAPIの方がビジネス・チャンスの点でも、設計の最大の課題/技術的リスクの点でも、プライベートAPIを大きく上回ります。

実際、オープンAPIは、これまでにない多様な統合設計の課題をもたらすだけでなく（バックエンド・システムをハッカーから保護しながら外部の開発者に公開する方法など）、新しいビジネス・リスクも作り出します。概念化が不十分なオープンAPIのプログラムは、企業のコア・ビジネスの売り上げを減少させ、重要なビジネス資産を競合会社にさらすリスクがあります。

このようなビジネス上の検討事項は、技術設計の意思決定でも考慮する必要があります。第3章では、ビジネスの検討事項と技術の意思決定を整合させる方法について説明します。

設計の意思決定APIの設計の意思決定では、APIが接続する要素、つまり、インタフェースのいずれかの側、組織のITインフラストラクチャ内と企業のファイアウォールの外部の両方にある要素を重視する必要があります。以下の2つの質問に回答すると、その要素を特定できます。

第2部: APIのビジネス・バリューチェーン

8

SOAではこれまで組織のプロセス改善を追求してきたのに対し、APIプログラムではビジネスの収益増加を追求します。そのため、APIの設計の意思決定は、企業のAPIプログラムの中核となる戦略的ビジネス目標に焦点を合わせる必要があります。APIの設計を始める前に、APIプログラムによって解決する問題、チャンス、およびそのチャンスを実現する方法を明確にする必要があります。以下の2つの質問に回答すると、それらを特定することができます。

• どのような資産を使用できるか。• APIによって、どのようにそれらの資産を提供するか。• APIに対してどのようなアプリケーションを構築できるか。• 開発者にAPIの使用を促すにはどうすればいいか。• アプリケーションによってビジネスにどのような方法で価値を創出するか。

コミュニケーションとコラボレーションは、このような課題とチャンスに対応するAPIを設計する上で重要な鍵になります。インタフェースの設計、デプロイ、管理のプロセスを通して、プログラム・マネージャとAPIアーキテクトは中核の戦略的目標、その目標を達成するために必要な作業、およびその作業の結果の評価方法に合意し、緊密なコラボレーションに取り組む必要があります。特に、ビジネス部門と技術部門は以下に合意する必要があります。

• プログラムの目標達成と理想的な最終状態• 組織がこれらの目標を達成するための最初のタスク• 成功の評価に使用する主要な測定基準 • プログラムで目標達成を維持するための継続的な日々の作業

第3部: ビジネス目標とAPI設計の整合

9

図3: API目標の整合

コミュニケーションが確立されて目標、タスクおよび測定基準が合意されたら、API設計の実際の作業を開始できますが、これについては第4部で説明します。

APIの支持者APIのプログラム・マネージャ APIアーキテクト

対象タスクの測定基準

対象の開発者ビジネス・リーダー

技術リソース収益のチャンス

第3部: ビジネス目標とAPI設計の整合

スポンサーの任命ビジネス・マネージャとアーキテクトが合意するために、プログラムには技術部門、ビジネス・マネージャ、アプリケーション開発者の間の見解の相違を解消することのできる「スポンサー」が必要です。多くの組織は技術以外のマーケティング・マネージャにこの役割を任命しますが、それは誤りです。スポンサーは「APIの支持者」であり、組織のアーキテクチャの制約を理解し、アプリケーション開発者の熱意を共有できなければなりません。

支持者の役割は、特に以下を促すために、すべての関係者と明確なコミュニケーションを確立することです。

• エグゼクティブなどの上層の意思決定者によるAPIプログラムの「受け入れ」

• APIアーキテクトによるプログラム・マネージャのビジネス目標の明確な理解

• アーキテクトの技術的なリソースおよび制約に対するプログラム・マネージャの理解

• 対象の開発者の好みと要件に関する情報収集

10

APIのビジネス戦略に関する注意プログラム・マネージャ（または「APIオーナ」）は組織のAPI支持者とのコラボレーションによって、APIの明確なビジネス戦略を策定し、その戦略をエグゼクティブレベルの意思決定者、およびその戦略の技術面を担当するアーキテクトと開発者に伝えることに責任を負います。

最初の手順は、会社のより広いビジョンに整合したAPIプログラムの明確な事業達成目標とビジョンを説明することです。APIは純粋な技術ソリューションではなく、製品または戦略として扱い、全社的なビジネス戦略に組み込む必要があります。

これを念頭に、次の手順でこのビジョンに基づいてビジネス・モデルを構築し、以下の詳細を説明します。

コスト、リソース、効率性

• プログラムで使用するシステム、関係、アクティビティ、およびその他のリソースとこれらのリソースを活用するために企業を強化する方法

価値、収益、革新• 顧客、市場、チャネルを対象としたプログラム、および技術革新によってこれらの対象から新しい収益を創出する方法

このビジネス・モデルは、APIプログラムがビジネスに提供する現実的で測定可能なビジネス価値を明確に説明し、価値ある提案をすることがその中核になります。

第3部: ビジネス目標とAPI設計の整合

第4部: 採用されるAPIの設計技術的には、APIの設計は比較的簡単です。しかし、ビジネスに真の価値を提供する設計となると複雑になります。機能に加え、エンタープライズ・アーキテクトはビジネス目標とエンドユーザ・エクスペリエンスも考慮する必要があります。

SOAプロジェクトをAPIの領域にまで拡大する場合は、特に複雑になる可能性があります。SOAではアーキテクトのニーズが中心で、ユーザが採用することが前提になっています。そのため、SOAの経験のあるアーキテクトは、インタフェースとアプリケーションのユーザはニーズもこだわりも同じであることを前提にAPIの設計の意思決定を行います。しかし、このような意思決定による設計は多くの場合、不適切です。

APIでは設計の中心は機能ではなく、ユーザ・エクスペリエンスにする必要があります。重要なのは、「どのような機能を提供するか」ではなく、「開発者はどのようにこのインタフェースを使用するか」です。開発者がAPIを使用しなければ、そのAPIに価値はありません。そのため、設計は開発者中心で、対象の開発者の利用の妨げになる要素を最小限にすることを重視します。

プライベートAPIでもパブリックAPIでも、優れた開発者エクスペリエンス（DX）は成功に必要不可欠です。DXの定量化は機能の定量化よりはるかに困難です。DXは、APIプロバイダと開発者の対話の多さによって決まりますが、その多さは数値ではなく感情的なものです。つまり、開発者がインタフェースに対してどのように感じるかが重要になります。

これは曖昧な測定基準ですが、APIの設計の異なるアプローチ対して開発者がどのように感じるかを理解するために現実世界で実行できる実用的な手順は確かにあります。たとえば、以下のような手順です。

• 開発者のプロファイルを作成する• フィールドでAPIのプロトタイプを作成してテストする

11

12

開発者のプロファイル対象の開発者のニーズと好みを知らなければ、採用されるAPIを構築することはできません。APIのクライアント・アプリケーションを構築する開発者は若く、自らを「ハッカー」と称し、最新の言語とプロトコルばかりを考えていると思われる傾向があります。しかし、多くの場合、特にプライベートAPIのシナリオでは、エンタープライズ・サービスの開発者はより洗練された手法に忠実です。

重要なのは、APIプロジェクトを成功させるためには、特定の開発者層のニーズに対応する必要があるということです。開発者層は共通のニーズを持つ同種のグループの場合もあります。また、多様な好みに対応しなければならない場合もあります。いずれにしても、APIを使用する開発者と、開発者が迅速かつ効率的にバックエンド・リソースを使用できるインタフェースを定義する方法を理解する必要があります。

そのため、最初の一歩はAPIの対象となる開発者の人物像（1つまたは複数）を考え、タイプ（1つまたは複数）を定義します。これには以下の情報を含めます。

• アプリケーションを使用するユーザ（およびその部署）とアプリケーションを開発する理由

• プログラミングのスキル、技術的制約、および言語/プロトコルの好み

• 個人の性格と最も実力を発揮できる状況

プロトタイプ作成対象の開発者の作業の目標、技術的要件、および個人的な好みを把握したら、これらの基準に合わせてインタフェースの構築を開始できます。ただし、実際のデータやバックエンド・システムに連係させる本番のAPIを構築する前に、簡単に変更できる軽量のプロトタイプを構築します。このプロトタイプによって、対象ユーザに基づく仮の設計をテストします。

「使い捨て」のデータや機能を基に軽量のプロトタイプを作成する利点の1つは、最小限のセキュリティを適用して、開発者の利用の妨げになる要素を最小化できることです。それによって、対象の開発者のエンゲージメントが初期段階で可能になります。開発者はAPIの設計をテストする軽量のアプリケーションを作成し、フィードバックを提供します。その後、インタフェースを修正して再度テストします。これを何度か繰り返すことによって、正しい方向に向かうことができます。

もちろん、これらはいずれもインタフェースの設計に対する基本的かつ現実的な意思決定を目的としたものではありません。第5部では、実際のAPIの設計オプションについて説明します。

第4部: 採用されるAPIの設計

図4: APIプロトタイプ作成に便利なツール

軽量のAPIプロトタイプの構築とテストのプロセスを簡略化するさまざまなオンライン・ツールがあります。

一般的な例は、以下のとおりです。

コードを記述せずに、APIプロトタイプを迅速に構築する設計ツール

Apiaryaplary.lo

RAMLraml.org

SWAGGERswagger.io

開発者によるプロトタイプのインタフェースの検出、およびその使用開始に役立つAPI記述言語

123

13

APIのスタイルの選択は、インタフェース設計者の最も重要な意思決定の1つです。タイプの意思決定は必然的に、提供するバックエンド・リソースの固有の特徴やIT組織の制約など、技術的な検討事項に影響されます。また、その他にも、APIプログラムのビジネス目標、対象開発者のニーズや好みなどを考慮する必要があります。

現在一般的なAPI設計のスタイルは以下のように分類できます。

第5部: APIのスタイル

Webサービス （別名トンネリング）

Pragmatic REST （実用的なREST） （別名URI）

ハイパーメディア （別名True Rest）

イベント駆動型 （別名IoT）

14

Webサービスのスタイルは、伝送に依存しない運用ベースのAPI設計アプローチで、Web Services Description Language（WSDL）を使用してインタフェースを記述します。Webサービスは本来、SOAの分野でそのインタフェースが異種混合ネットワークの統合に使用されていました。そのため、SOAインタフェースにまで拡張するプログラムには適したスタイルです。また、Webサービスには多数のツールが存在するため、多くの場合、クライアント・アプリケーションを迅速かつ簡単に構築できます。

しかし、このスタイルの使用には重大な制限があります。まず、この伝送に依存しないスタイルは、HTTP（ハイパーテキスト・トランスファー・プロトコル）を使用できる反面、それでは効率が大幅に低下します。そのため、サービスを公開されたWebに拡張する場合は、最良の選択肢ではありません。

さらに、対象の開発者がWSDL、SOAP（Simple Open Access Protocol）、RPC（Remote Procedure Call）などのSOAの標準に慣れている場合にのみ実用的です。クライアント開発者の大半は、短時間で多くの知識を習得する必要があります。

これはオープンAPIのシナリオ、特にモバイル中心の開発者の場合に顕著です。基本的に、アプリケーション開発者はプログラム言語としてのSOAPは好まず、Webサービス・クライアントの構築に使用できるツールではモバイルはサポートされない傾向があります。実用的な検討事項のほかに、認識の問題もあります。Webサービスのスタイルを使用すると、動きの遅い「恐竜」のように思えるため、モバイル・アプリケーション開発者の採用率は減少します。

Pragmatic REST（Pragmatic Representational State Transfer）のスタイルはより単純で、よりWeb中心のアプローチで統合インタフェースを設計します。このスタイルではWSDLの代わりにURIを使用し、伝送に特化され（HTTPのみサポート）、エンタープライズAPI設計におけるWebサービスのスタイルの大半を引き継いでいます。実際、「Web API」という用語は、「RESTful API」と相互に言い換えることができ、「RESTfulness」の達成は多くの場合、あらゆるインタフェース設計プロジェクトの重要な目標と考えられています。

現在使用されているREST APIの大半は、2000年のRoy Fielding氏の博士号論文で概説されているRESTの基準に完全には一致しません。RESTは、Webを強化する動的なパイハーリンクされたインタラクションなどを形式的に記述するものと定義されているのに対し、多くのWeb APIは静的データの交換を扱います。そのため、便宜上、この設計スタイルは「Pragmatic REST（実用的なREST）」と呼ぶ方がより正確です。

Pragmatic RESTのスタイルが広く利用されるようになった理由は簡単です。URIは直観的で、Webとモバイルの開発者の大半はRESTfulのインタフェースの経験があるため、開発者による採用率と生産性が向上します。さらに、HTTPに集中しているため、Pragmatic REST APIは現在のWebおよびモバイル・アプリケーションの開発に理想的です。いまのところ、これはプロジェクトの大半にとって主力のスタイルになるでしょう。

ただし、Pragmatic RESTのスタイルは、すべてに対して完璧というわけではなく、将来も開発において優勢であるかは疑問です。また、このスタイルには、決定的な代償があります。それは、4つの手法に限られること、何度も呼び出しが必要であること、URIの設計が標準ではないことです。さらに、モノのインターネット（IoT）とビッグ・データによってオンライン・ネットワーキングは大幅に拡張および変化したため、特にWeb中心のこのアプローチには多くの課題があるでしょう。

Pragmatic REST

Webサービス

第5部: APIのスタイル

151515

ハイパーメディアAPIの設計スタイルは、Pragmatic RESTのより持続可能な選択肢を提供することを目的としたタスクベースのアプローチです。Pragmatic RESTと同様に、ハイパーメディアAPIは一般的に、URI、HTTP、およびRESTfulの標準を焦点にしています。ただし、ハイパーメディアのスタイルはFielding氏によると、ある意味、RESTfulのアーキテクチャをより忠実に適用しています。これは、Webが拡張性に優れていることが実証されている理由の説明にもなります。

そのため、ハイパーメディアのアプローチはよりWeb中心です。Webのハイパーリンクとフォームは、ハイパーメディアAPIがリンクを提供して、ワークフローと情報を要求するテンプレートの入力をナビゲートする方法に反映

されています。WebのRESTfulアーキテクチャが拡張性に優れ、高度な進化型であることが証明されたように、優れた設計のハイパーメディアAPIは新しいアプリケーションを何年にもわたってサポートできます。

Webおよびモバイル・アプリケーションを長期間、高信頼性でサポートできる拡張可能なAPIを構築しようとする企業にとって、このアーキテクチャのアプローチは魅力的なオプションである反面、新しい設計スタイルであるために関連ツールが非常に限られています。これは、開発者による採用率に影響し、開発者が強力なクライアント・アプリケーションを迅速に構築するにはこのAPIの採用はむずかしいでしょう。

Pragmatic RESTとハイパーメディアのようにHTTP中心のスタイルは、よく知られているように、Webおよびモバイル・アプリケーションにとっては理想的ではありますが、HTML5とIoTの出現によって状況が変化し、より動的なアプリケーションの可能性が生まれただけでなく、より軽量なインタフェースが必要とされるようになりました。このような背景から、イベント駆動型のスタイルが伝送に依存しない選択肢として登場しましたが、これは、HTTPに代わる新しいWebSocketなどをアプリケーションで使用するのに理想的です。

このスタイルは、サーバまたはクライアントで開始されたイベントが中心ですが、小規模なメッセージングが大量にバックエンドとアプリケーション間を通過するシナリオでは優れたパフォーマンスが提供されます。そのた

め、これはIoTと幅広いモバイルでの使用に理想的で、特に、インスタント・メッセージング、ビデオ・チャット、マルチプレーヤーのゲームなどに適しています。また、最先端の開発者にとっても魅力ある選択肢です。

もちろん、すべての開発者が最先端のアプローチを採用するわけではなく、従来のRESTfulのアプローチがより適切である場合も数多くあります。HTTPはいまでもWebを強化する伝送プロトコルですが、クライアントから送信されたイベントには特に十分対応できません。また、このスタイルを要求-応答モデルに適用した場合、開発者にとってクライアント・アプリケーションの構築はより複雑になります。

イベント駆動型

ハイパーメディア

第5部: APIのスタイル

16

選択したスタイルは技術的制約、ビジネス目標、開発者の好みに大きく影響されます。状況に対して不適切であるにもかかわらず、「流行」のスタイルを採用しないように注意してください。また、リソースは変化し、ユーザ層は増加し、オンライン・ネットワーキングは進化するものなので、長期的に拡張および適応が可能なスタイルを選択してください。

どのようなスタイルを選択しても、APIに含める必要のあるアーキテクチャ・コンポーネントがあります。 第6部では、そのようなコンポーネントとその体系化の方法について説明します。

図5: API設計のアーキテクチャ・スタイル

Webサービス Pragmatic REST ハイパーメディア イベント駆動型

SOA関連で多くのツールを 使用可能

モバイルには不適切

Web/モバイル・アプリケーションに 理想的

多くのアプリケーション開発者が経験 長期的な適応は疑問

高度にWeb中心 拡張可能/進化型

多くの開発者は未経験

IoTとデバイスには適切 軽量で動的

標準的なシナリオには不向き

第5部: APIのスタイル

17

図6: アーキテクチャ・レイヤ

先に説明したアーキテクチャの設計スタイルでは、API実装の独自の機能を可能にするアーキテクチャ・フレームワークの設計に関するモデルを提供する必要があります。使用事例によっては、特定の設計スタイルを実装することが求められます。また、使用事例にかかわらず、APIのアーキテクチャに含める必要のあるコンポーネントは多数あります。

このような一般的なアーキテクチャ・コンポーネントは、どのAPI実装にも組み込まないでください。その代わりに、組織のAPIとそのAPIを利用するクライアント・アプリケーションの間に配置されたAPIのコア・インフラストラクチャに導入します。これらのコンポーネントを排除すると、追加のAPIの設計が迅速化および簡略化され、幅広いAPIを調和させて更新し、API、バックエンド・システム、およびクラアント・アプリケーションをスムーズに実行できます。

効果を最大化するために、これらのコンポーネントはレイヤ形式で構築し、すべてのデータ・トラフィックは右の図で示した各レイヤをこの順番で通過するようします。

第6部: APIのアーキテクチャ

セキュリティ・レイヤ

キャッシング・レイヤ

リプレゼンテーション・レイヤ

オーケストレーション・レイヤ

クライアント・アプリケーション

エンドユーザ

バックエンド・システム

API実装

セキュリティ・レイヤAPIはビジネス・チャンスを拡大すると同時に、機密のバックエンド・システムとデータを外部に提供するため、企業が新しいセキュリティの脅威にさらされる可能性も拡大します。APIはWebを悩ませてきたセキュリティの脅威の大半、およびAPI固有の新しい脅威に対して脆弱です。そのため、強力なAPI固有のセキュリティをAPIアーキテクチャのエッジに配置することは不可欠です。

このように強力なセキュリティが必要であることは、優れたAPIの設計によって企業のリソースにシームレスにアクセスできるアプリケーションを開発者が簡単に作成できるというAPI設計の基本的な目標に反するかもしれません。強力なセキュリティはシームレスなアクセスに影響します。一元化されたAPIアーキテクチャ（API実装ではない）にセキュリティをデプロイすると、OAuthやOpenID Connectなどの柔軟なアクセス管理テクノロジを使用できるため、このような影響が緩和されます。

キャッシング・レイヤユーザによるAPIプログラム採用とユーザ維持の目標を達成するには、開発者とエンドユーザにスムースなエクスペリエンスを提供する必要がありますが、そのためには、インタフェースの効率は不可欠です。APIの効率を最大化する方法の1つは、キャッシング・レイヤをAPIアーキテクチャのエッジ近くに配置することです。このレイヤではキャッシュした応答を一般的な要求に送信して、API実装とバックエンド・リソースへの負荷を軽減します。

リプレゼンテーション・レイヤAPIのプレゼンテーションでは、可能な限り開発者の使いやすさを考慮します。この要素を実装から独立して抽象化することで、APIやバックエンドのリソースに影響せずに、使いやすいAPIを構築できます。それによって、複雑なバックエンド・システムをWebおよびモバイル中心のインタフェースとして提供することが大幅に簡略化され、開発者はすぐに理解して、ユーザ中心の強力なアプリケーションの開発に活用できます。

オーケストレーション・レイヤアプリケーションによっては、単一のAPIで単一のリソースにアクセスすることで価値が提供される場合もありますが、複数のAPI（他社のAPIを含む）とバックエンド・リソースからのデータを組み合わせることで可能性は大幅に拡大します。オーケストレーション・レイヤをインタフェースの隣に配置することで、このような組み合わせが可能になり、複数のバックエンド・リソースからの新しい実装の構成プロセスも簡略化されます。

一元化されたAPIアーキテクチャを効率的に構築するには、API管理ソリューションをデプロイします。第7部では、API管理の主要なコンポーネントについて説明します。

18

第6部: APIのアーキテクチャ

セキュリティで保護された開発者中心のAPIの一般的なアーキテクチャ・コンポーネントを一元化するインフラストラクチャを構築すると、ビジネスに価値を追加するAPIの実装プロセスが大幅に簡略化されます。ただし、このようなインフラストラクチャを社内で構築することは非常にむずかしい場合があります。ありがたいことに、エンタープライズ・ソフトウェアのベンダは現在、多様な「API管理」ソフトウェアを提供しているため、この重要なインフラストラクチャを社内で開発する必要はありません。

さらに、名前が示すように、API管理ソリューションには長期にわたってAPIのパフォーマンスを管理および最適化する機能も含まれます。また、最も強力なソフトウェアには、開発者がAPIを検出、習得およびアクセスするのに使用できるWebベースのインタフェースを構築する機能も備えています。これは、開発者中心のAPIを提供するのに絶対的に不可欠な部分ですが、実装自体に組み込むことができません。

第7部: API管理

19

API管理は単なる技術的要件ではないことに注意してください。エンタープライズAPIのプログラムのビジネス面での成功において、避けることのできない重要な役割を担います。エンタープライズAPIの構成、パフォーマンス、およびセキュリティの管理は、APIプログラムに対する投資をスムースに回収するために不可欠です。同様に、ビジネス価値を創出するアプリケーション構築するためには、開発者を積極的にエンゲージメントおよび管理する必要があります。

多くの企業にとって、API管理インフラストラクチャは開発者が強力な新しいアプリケーションの構築に使用するAPIの設計、デプロイ、および維持に必要です。

20

図7: API管理コンポーネント

アプリケーション開発者

クライアント・ アプリケーションエンドユーザ

APIオーナ

API実装

開発者用ポータル

APIゲートウェイ

第7部: API管理

API管理の5本の柱によるAPI管理の必須要素に関するeBook

APIアーキテクト

バックエンド・システム

API管理コンポーネントエンタープライズレベルのAPI管理ソリューションには、2つの主要なコンポーネントがあります。

• APIゲートウェイ – APIコア・アーキテクチャのデプロイに必要なセキュリティ、キャッシング、およびオーケストレーションの機能• 開発者用ポータル – 開発者がAPI、ドキュメンテーション、コミュニティ・フォーラムなどの有益なコンテンツにアクセスするためのカスタマイズ可能なインタフェースを提供

2121

アーキテクチャの観点では、APIはSOAを拡張したものです。組織の境界を拡大するために、SOAで構築したインタフェースによってレガシー・システムをオープン・システムにして新しいサービスで再利用するように、モバイル・デバイスや公共のWebのアプリケーションを構築するために、APIによって企業のバックエンドを開発者に提供します。これは、大幅な拡張のため、Web APIの設計要件はSOAのWebサービスの設計要件とは大きく異なるかもしれません。

SOAプログラムは一般的に、ITコスト削減が重視されるのに対し、APIプログラムは新しい収入源の創出が重視されます。Web APIは既存のさまざまなビジネス資産を接続し、これまで予測もつかなかった方法で価値を創出します。優れたAPIの設計では、常にビジネスの成果が重視されます。そのため、APIの設計とアーキテクチャのプラクティスは、組織のビジネス戦略と完全に整合させる必要があります。

APIのオーナとアーキテクトはコミュニケーションによって、主要な目標とその達成方法、および成功の評価方法に合意する必要があります。効果的なコミュニケーションのために、API支持者にはビジネスと技術の役割間のギャップを埋め、ビジネス・リーダー、APIオーナ、アプリケーション開発者およびエンタープライズ・アーキテクトのニーズを説明し、適切な対象、タスクおよび測定基準を交渉する能力が必要です。

実際には、ビジネスを成功させるAPIの設計とは、開発者が使用したいと思うインタフェースを構築することを意味します。そのため、構築する前に、開発者を体系的に調査して、対象の開発者とそのAPIに対する希望を理解することは重要です。また、軽量のAPIのプロトタイプを提供して、開発者の好みに関する仮定をテストすると効果的です。

まとめ

API実装の設計の準備ができたら、プロジェクトに最適なデザイン・スタイルを選択します。WebサービスAPIはSOAの経験のある開発者を対象とした社内プログラムの構築に適しています。Pragmatic REST APIはモバイル・デバイスとWebを中心としたオープンAPIのプロジェクトに適しています。ハイパーメディアとイベント駆動型のスタイルは、モバイルおよびIoTを中心とした、長期的に持続可能なアプローチとして新たに考えられたスタイルです。

どのスタイルであっても、すべてのAPIに含める必要のあるアーキテクチャの要素があります。それは、セキュリティ、キャッシング、リプレゼンテーション、オーケストレーションです。効率と管理性を最大化するために、これらの要素は個々のAPI実装には組み込まないでください。代わりに、すべてのAPIで、企業のエッジとAPIの間に位置する一元化されたレイヤ型のAPIアーキテクチャを活用します。

一元化されたAPIアーキテクチャを最も効率的かつ効果的にデプロイし、APIプログラムを長期的に成功させるためには、API管理ソリューションを採用します。市場には多様なソリューションがありますが、その大半に以下の2つのコンポーネントが含まれています。

• セキュリティ機能と他の重要なインフラストラクチャを提供するAPIゲートウェイ

• 開発者のエンゲージメント・プロセスを簡略化し、効果的な作業を可能にする開発者用ポータル

現在のエンタープライズAPIプロジェクトには、大きなビジネス・チャンスや深刻なセキュリティ・リスクなど、さまざまな要素があります。APIの構築を開始する前の準備として、ビジネス目標と設計目標の整合、対象開発者の好みの確認、適切な実装スタイルの選択、およびAPI管理インフラストラクチャのデプロイを行うことは必要不可欠です。そうすれば、真に価値のあるAPIを構築することができます。

22

図8: 優れた設計の前提条件

技術の目標とビジネス目標の整合 開発者の好みの確認 API設計スタイルの選択 APIインフラストラクチャのデプロイ

まとめ

$

システムの統合、アプリケーション開発の簡略化、データの収益化を実現すると同時に、現在必要とされるAPIのセキュリティと保護を提供できるのはCA API Managementだけです。CA API Managementの詳細については、ca.com/jp/apiをご覧ください。

Copyright ©2015 CA. All rights reserved. 本書に記載のすべての商標、商号、サービスマーク、ロゴは、該当する各社に帰属しています。本書に記載の情報や結果は、顧客に固有の使用状況と経験に基づいたもので、実際の結果は異なる場合があります。本文書は情報参照のみを目的としています。

CS200-131275

CA Technologies (NASDAQ:CA）は、企業の変革を推進するソフトウェアを作成し、アプリケーション・エコノミーにおいて企業がビジネス・チャンスを獲得できるよう支援します。ソフトウェアはあらゆる業界であらゆるビジネスの中核を担っています。プランニングから開発、管理、セキュリティまで、CAは世界中の企業と協力し、モバイル、プライベート・クラウドやパブリック・クラウド、分散環境、メインフレーム環境にわたって、人々の生活やビジネス、コミュニケーションの方法に変化をもたらしています。詳細についてはca.com/jpをご覧ください。

CA API Managementについて 通信、金融サービス、政府機関、小売業など、多様な業種300社以上に利用されているAPI Managementを通して、CA TechnologiesはAPIを活用して価値を提供するのに必要な業界最先端のテクノロジとノウハウを提供しています。CAは軍事グレードのセキュリティ機能や開発者用ポータルなど、完全な機能を備えたAPIゲートウェイを含む完全なAPI ManagementソリューションをオンプレミスとSaaSの両方で提供しています。CA API Managementの詳細については、ca.com/jp/apiをご覧ください。

APIアカデミー APIの戦略、アーキテクチャ、および設計サービスCA Technologiesが編成するAPIアカデミー・チームは業界の専門家で構成され、コミュニティのために無料のリソースを開発し、APIプログラムの向上を希望する組織に専門コンサルティング・サービスを提供しています。APIアカデミーが御社のAPI戦略、アーキテクチャ、および設計でどのように貢献できるかについては、apiacademy.comをご覧ください。