以下のコンセプトの中には、一般的なアイデアであっても Apigee では独自の意味合いを持つものがいくつかあります。
用語 | 定義 |
---|---|
API |
「アプリケーション プログラミング インターフェース」の略であり、あるアプリケーションで別のアプリケーションの機能やデータを「使い」やすくするインターフェースです。 アプリケーションのロジックやデータに対する持続性のあるシンプルなエントリ ポイントを定義することで、他のデベロッパーによって構築されたアプリケーション ロジックへのアクセスやそれらの再利用を簡単にします。「Web API」の場合は、ロジックやデータがネットワーク経由で公開されます。API を使用するアプリケーションは変更による影響を受けやすいため、API には「契約」もその意味に含まれます。この契約では、時間の経過とともに予期可能な方法で API が変化することがある程度保証されます。 Apigee では、API そのものや、API の開発と使用に関するおすすめの方法について、豊富な情報を提供しています。始めるには、API 設計ウェブキャストや、無料の電子ブック『Web API 設計: デベロッパーが求めるインターフェースの作成』をご覧ください。 |
API プロキシ |
Edge が提供する、1 つまたは複数の API、各種汎用 HTTP サービス、アプリケーション(Node.js など)へのファサードです。 API プロキシは、Apigee Edge によって提供されるリソースセットに依存する一連の構成ファイル、ポリシー、コードとして実装されます。API プロキシは、Apigee Edge 管理 UI を使用して生成および構成することも、テキスト エディタや IDE でローカルに実装することもできます。 API プロキシが提供するファサードは、デベロッパーに公開される API を「バックエンド」サービスから切り離すことで、社内デベロッパー チームに影響を与えることなく、デベロッパーをコード変更から保護し、最先端のイノベーションを実現します。開発チームがバックエンドに変更を行っても、デベロッパーは何の妨げもなく同じインターフェースを引き続き呼び出せます。Apigee を採用することで、複数のインターフェースを同じ API に公開でき、API のシグネチャを自由にカスタマイズして、デベロッパーのさまざまな分野におけるニーズを同時に満たすことができます。 |
API のベースパスとリソース |
ネットワークアドレスと URI で定義される API です。API は「ベースパス」と一連の「API リソース」で構成されます。各 API プロキシはベースパスを定義し、必要に応じて複数の API リソースパスも定義します。API は単純に一連の URI であると考えることができます。すべての API は共通のベースパスを共有します。 API を管理しやすくするため、Apigee ではこれらの元になる URI に表示名と説明を付加しています。Edge を使用すると、URI にポリシーやコードを接続して、API の動作を細かく制御したり管理したりできます。 |
API プロダクト |
API リソースのコレクション(URI)にクォータや「サービスプラン」を組み合わせたコレクションであり、設計時にアプリのデベロッパーに公開されます。API プロダクトは、収益化のために、API パッケージとしてバンドル化できます。 API キーは 1 つまたは複数の API プロダクトにバインドされ、アプリと、アプリでの使用が許可された URI のバンドルとの間のバインドを強制します。 |
API パッケージ | デベロッパーにバンドルとして提供される API プロダクトのコレクションであり、通常は収益を得るために定義された料金プランと関連付けられています。 |
アプリ |
「アプリケーション」の略語です。「アプリ」という用語は、API を使用するモバイル アプリケーションを指すようになりました。デベロッパーはさまざまなプログラミング言語で、多様なテクノロジーとプラットフォームを使用してアプリを実装します。API の使用を希望するデベロッパーは、Apigee Edge 上で API プロバイダの組織にアプリを登録します。 アプリが登録されると、そのアプリを識別する API キーとシークレットが Apigee によって生成されます。デベロッパーはその API キーをアプリに埋め込み、アプリはリクエストの実行時にそのキーを提示します。API Services は、直接的な API キー検証や OAuth を通じて、API キーに関連するセキュリティ保護を実装します。 |
環境 |
API プロキシのランタイム実行コンテキストです。ネットワーク経由で API にアクセスできるようにする前に、API プロキシを環境にデプロイする必要があります。デフォルトで、組織には「test」と「prod」という 2 つの環境がプロビジョニングされます。
|
組織 |
API プロキシ、API プロダクト、API パッケージ、アプリ、デベロッパーなど、Apigee Edge アカウントに含まれるあらゆるオブジェクトのコンテナです。 ユーザー アカウントは、所属する組織ごとに必要です。(ほとんどのユーザーは 1 つの組織にのみアカウントを保持します。) |
ポリシー |
API プロキシ処理フロー内において、ロジックのアトミックで再利用可能な単位として実行される処理ステップです。 一般的なポリシーベースの機能には、メッセージの形式変換、アクセス制御の適用、追加情報を要求するリモート サービスの呼び出し、機密情報の外部ユーザーからの秘匿、潜在的な脅威を探すためのメッセージ内容の検証、一般的なレスポンスのキャッシュ処理を通じたパフォーマンス向上などがあります。 ポリシーは、リクエスト メッセージやレスポンス メッセージの内容やコンテキストに基づき、条件に応じて実行できます。たとえば、リクエスト メッセージがスマートフォンから送信されてきた場合に、変換ポリシーを実行してレスポンスの形式をカスタマイズできます。 |
API リソースパス | RESTful コンセプトの 1 つであり、特定のリソースまでのネットワーク パスを指定する統一リソース識別子(URI)です。 |
バージョン |
デベロッパーに公開されている API インターフェースのバージョンです。 たとえば、 この用語と「リビジョン」は用途が区別されます。リビジョンは、構成やポリシーをバンドルして API プロキシとしてまとめたもので、バージョン管理された番号付きパッケージを指します。API インターフェースにはバージョンがあり、API プロキシにはリビジョンがあります。 |
リビジョン | 構成やポリシーをバンドルして API プロキシとしてまとめた、バージョン管理された番号付きパッケージです。この用語と「バージョン」は用途が区別されます。バージョンは、デベロッパーに公開されている API インターフェースを指します。上欄の説明をご覧ください。 |