API 開発のライフサイクル

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

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

API Services の API については、API リファレンスに説明があります。詳しくは、API リファレンス スタートガイドをご覧ください。

API 環境と API 開発ライフサイクルの概要を説明する動画もご覧ください。

環境

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

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

受信用サーバーの TLS / SSL は各環境用に自動で有効にされます。各環境には 2 つの VirtualHost（default と secure）が事前に定義されています。default が HTTP アドレスを定義するのに対し、secure は事前構成済みのサーバー側 TLS / SSL を使用して HTTP/S アドレスを定義します。API プロキシ構成では、ProxyEndpoint がリッスンする VirtualHost を指定します。prod に昇格させる際には、通常、default VirtualHost を API プロキシ構成から削除して HTTP を無効にします。

たとえば、次の 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 に昇格させます。

詳細については、デプロイについてをご覧ください。

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

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 構成を作成できます。バックエンド サーバー間の負荷分散をご覧ください。
  • キャッシュと Key-Value マップ: どちらの永続性リソースのスコープも環境で決まります。昇格中に構成を変更しなくても API プロキシがデータを保存できるような命名規則を使用してください。環境キャッシュの作成と編集をご覧ください。
  • ServiceCallout ターゲット: test 環境の ServiceCallout がデモサービスを使用する場合など、ServiceCallout が環境に応じて異なるターゲットを使用することがあります。Service Callout ポリシーをご覧ください。

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

詳細については、デプロイについてをご覧ください。