Send Docs Feedback

Note: Most user interface tasks can be performed in Edge Classic or the New Edge experience. For an overview, getting started topics, and release notes specific to the New Edge experience, see the docs.

API 開発のライフサイクル

どの組織にも独自のソフトウェア開発ライフサイクル (SDLC) があるものです。往々にして、API プロキシ展開の同期と配置には、他のアプリケーションの開発、テスト、展開に現在用いられているのと同じプロセスを経ることが必要となります。

API Services は、API プロキシの展開と管理を組織の SDLC に統合できるようにするツールと RESTful API を提供します。RESTful API の一般的な用途は、他のアプリケーションの展開や移行も伴うより大掛かりな自動処理の一環として、API プロキシをプログラム的に展開したり API プロキシを環境間で移行したりするスクリプトやコードを作成することです。API Services は、組織の SDLC を (そしていかなる類いの SDLC も) 想定しません。逆に、展開担当チームが API 展開ライフサイクルを自動化および最適化するために調整できるアトミック関数が公開されています。

API Services の API については、API リファレンスに説明があります。「API リファレンスについて」を参照してください。

Watch this video for an introduction to API environments and the API development lifecycle.

Environments

Apigee Edge 上のどの組織にも、API プロキシに使用できる展開環境 (environment) として少なくとも「test」と「prod」の 2 つがあります。この 2 つの環境の区別は任意です — 各環境は異なるネットワークアドレス (URL) 一式だけで識別します。 目的は、API を外部デベロッパに公開する前に、API プロキシを構築して検証できるドメインを提供することです。

これらの環境を活かして、行われた API プロキシ開発を自組織の SDLC と同期させることができます。各環境は 1 つのネットワークアドレスで定義され、作業中の API プロキシ間のトラフィックと、実行時にアプリによってアクセスされる API プロキシ間のトラフィックとを、分離できます。各環境で使用できるネットワークアドレスは、その環境で使用できる VirtualHost 一式に定義されています。

Inbound, server TLS/SSL is automatically enabled for each environment. Two VirtualHosts are pre-defined in each environment: default and secure. Default defines an HTTP address, while secure defines an HTTP/S address, with pre-configured server-side TLS/SSL. In an API proxy configuration, you indicate which VirtualHosts the ProxyEndpoint should listen on. When promoting to prod, you typically disable HTTP by removing the default VirtualHost from the API proxy configuration.

例えば、以下の ProxyEndpoint は HTTP と HTTPS を受信待機します。

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

HTTPS のみ受信待機して HTTP を待機しない API プロキシを作成するには、default VirtualHost を ProxyEndpoint 構成から削除します。

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

環境で使用できる VirtualHost は、管理 UI メインメニューで「Environments」を選択して確認できます。

環境では、データとリソースも分離できます。例えば、test と prod とで別個のキャッシュをセットアップすると、該当する環境で実行される API プロキシだけがアクセスできるようになります。また、test 環境で発行された API キーは prod 環境では無効で、その逆も同様です。

環境への API プロキシの展開

API プロキシを作成する際には、どの環境で作業するかを決める必要があります。本運用環境で新しい API プロキシを作成することもできますが、準備が整う前に API がデベロッパに公開される可能性があり、お勧めできません。一般には、まず API プロキシを test に作成し、テストした後に prod に「昇格」させます。

ユーザーの役割によっては、展開できない環境が存在することがあります。例えば、役割が「user」の場合は test 環境にしか展開できません。管理者であれば、どの環境にも展開できます。

詳細については、「展開について」を参照してください。

テストにおける更新バージョン開発

API プロキシに対する作業中、API Services は構成の更新バージョンをリビジョンとして保存します。API プロキシを展開する際には、特定のリビジョンを選択して展開します。通常は最も新しいリビジョンを展開し、必要に応じて以前のリビジョン番号に戻します。リビジョンの展開先を選択できます。例えば、あるリビジョンを prod に昇格させて、デベロッパが API を使用して作業を始められるようにできます。同時に、テストで機能を追加したりポリシーを微調整したりして、リビジョンの更新を続けることができます。この場合、準備が整ったら新しいリビジョンを prod に展開して、その環境の既存のリビジョンを上書きできます。この方式を用いると、開発を進めながら最新リビジョンの API をデベロッパに提供できます。

prod への昇格

API プロキシが完全に実装され、テストされたら、prod に昇格させる準備が整います。 prod に展開される API プロキシのリビジョンは、test の API プロキシのリビジョンを使用して上書きされます。

API Services は、API プロキシをシームレスに展開できるようにする機能を提供して、展開手続き中のアプリやエンドユーザーへの影響を最小限に抑えます。

展開スクリプトの作成

Apigee Edge 管理 UI を使用すると、API プロキシをAPI プロキシビルダから prod に 直接展開できます。ただし多くの場合、セキュリティ、信頼性、整合性の要件により、開発チームは展開手順のスクリプト化を義務付けられます。スクリプト化するには、API Services によって公開される RESTful API を呼び出すコードやスクリプトを作成します。

環境リソース

昇格中の管理を強化するため、API プロキシのバージョン更新は test においてだけにとどめ、prod に展開された API プロキシへの変更はできるだけ少なくします。

このようにするには、各環境に関連する特定のリソースを、API プロキシ構成において静的であり続けられるように構成します。

  • ターゲット URL: 一般に、API プロキシはテスト中や本運用中にさまざまなバックエンド URL を呼び出します。TargetServer 構成を使用すると、環境に依存しない TargetEndpoint 構成を作成できます。「バックエンドサーバー間の負荷分散」を参照してください。
  • キャッシュとキー/値マップ: どちらの永続性リソースのスコープも環境で決まります。昇格中に構成を変更しなくても API プロキシがデータを保存できるような命名規則を用いていることを確認してください。「環境キャッシュの作成と編集 」を参照してください。
  • ServiceCallout ターゲット: test 環境の ServiceCallout がデモサービスを使用する場合など、サービスコールアウトが環境に応じて異なるターゲットを使用することがあります。「Service Callout ポリシー」を参照してください。

API プロキシ構成が環境に依存しないようにするために、条件文を使用することもできます。environment.name 変数を使用して構築された条件文は、現在の環境を評価するために、ポリシーを強制する前またはバックエンドで URL をルーティングする前に使用できます。

詳細については、「展開について」を参照してください。

Help or comments?