このページの内容は Apigee と Apigee ハイブリッドに該当します。
Apigee Edge のドキュメントを表示する。
以下のセクションでは、Apigee を使用した API 開発のライフサイクルについて説明します。
API プロキシの開発
Apigee では、反復型 API プロキシの開発向けに次の選択肢をサポートしています。
API プロキシの詳細については、API と API プロキシについてをご覧ください。
Apigee を使用したクラウド開発
Apigee が提供する API プロキシの編集ツールとデバッグツールを使用して、API プロキシを開発します。API プロキシで作業中、Apigee は構成の反復処理をリビジョンとして保存します。
API プロキシをデプロイする際は、デプロイする特定のリビジョンを選択します。通常は最新のリビジョンをデプロイし、必要に応じて以前のリビジョンに戻します。API プロキシのデプロイをご覧ください。
Apigee を使用して API プロキシの開発を始めるには、シンプルな API プロキシの構築をご覧ください。
Apigee in VS Code を使用したローカル開発
Apigee in Visual Studio Code（VS Code）を使用して API プロキシを開発し、単体テストと手動テストを通じて機能を検証します（たとえば、リクエストを送信して結果を表示します）。
ローカル検証が完了したら、API プロキシ構成をアーカイブとして Apigee 環境にデプロイします。API プロキシのデプロイをご覧ください。
Apigee in VS Code を使用してローカルで API プロキシを開発する方法については、Apigee in VS Code を使用した初めての API プロキシの構築をご覧ください。
API プロキシの展開
API プロキシをデプロイする環境を作成します。異なる環境の区別は任意です。各環境は、単に異なるネットワーク アドレス（URL）のセットで識別します。その目的は、API を外部のデベロッパーに公開する前に、API プロキシを構築して検証できるドメインを提供することです。詳細については、環境と環境グループについてをご覧ください。
API を複数の環境にデプロイすることで、テスト環境で作業中の API プロキシのトラフィックと、本番環境での実行時に外部アプリによってアクセスされる API プロキシのトラフィックを分離できます。
Apigee では、環境で次のデプロイ タイプがサポートされています。
| タイプ | 説明 |
| プロキシ | Apigee 開発環境で API プロキシを開発してテストし、Apigee 統合テスト環境と本番環境にデプロイします。API プロキシのデプロイをご覧ください。 |
| アーカイブ | VS Code での Apigee を使用したプログラム可能な API プロキシを開発およびテストします。 |
ポリシーの追加
Apigee では、ポリシーを使用することで、コードを記述することなく API の動作を制御できます。ポリシーは、特定の限定的な管理機能を実装するモジュールに似ています。ポリシーを使用すると、一般的な管理機能を簡単かつ確実に API に追加できます。ポリシーによって、セキュリティ、レート制限、変換、メディエーションの機能などが提供され、自身でコーディングやメンテナンスを行う必要がなくなります。 API プロキシの機能を拡張し、Apigee ポリシーでサポートされている基本的な管理機能を基にイノベーションを実現するカスタム スクリプトとコード（JavaScript アプリケーションなど）を作成することもできます。Apigee ポリシーの詳細については、ポリシーとはをご覧ください。
Apigee では、トラフィック管理、セキュリティ、メディエーション、拡張機能ポリシーなどのさまざまな機能に対するポリシーをすぐに使用できます。Apigee で利用可能なポリシーの完全なリストについては、ポリシー リファレンスの概要をご覧ください。
本番環境への昇格
API をデプロイする場所を選択します。たとえば、あるリビジョンを本番環境に昇格させて、デベロッパーが API の使用を開始できるようにします。同時に、ローカル環境やテスト環境で複数のリビジョンを反復処理して、機能の追加や、ポリシーの微調整を行えます。その後、準備が整ったら、新しいリビジョンを本番環境にデプロイし、その環境の既存のリビジョンを上書きできます。この方式を使用すると、新しい機能の開発やテストを行いながら、デベロッパーが API のライブ リビジョンをいつでも利用できます。
Apigee API を使用したデプロイのスクリプト作成
Apigee には、API プロキシのデプロイと管理を組織のソフトウェア開発ライフサイクル（SDLC）に統合できる RESTful API が用意されています。たとえば、セキュリティ、信頼性、整合性の要件を確実に満たすために、Apigee API の一般的な用途は、API プロキシをプログラムでデプロイして大規模な自動化プロセスの一部として、ある環境から別の環境にプロモートするスクリプトやコードを記述することです。
詳細については、Apigee API をご覧ください。
環境リソースの管理
環境によって、データとリソースを分離できます。たとえば、その環境で実行されている API プロキシのみがアクセスできるキャッシュを test 環境と production 環境に分けて設定できます。また、テスト環境で発行された API キーは本番環境では有効でなく、その逆も同様です。
昇格中の管理を強化するため、API プロキシのバージョン更新はテスト環境でのみ行い、本番環境にデプロイされた API プロキシへの変更はできるだけ少なくします。
このようにするには、各環境に関連する特定のリソースを、API プロキシ構成において静的であり続けられるように構成します。
- Key-Value マップ（KVM）: 環境をスコープとしている場合、昇格中に構成を変更しなくても API プロキシがデータを保存できるような命名規則を使用してください。詳細については、Key-Value マップの使用をご覧ください。
- ターゲット URL: 一般に、API プロキシはテスト環境や本番環境でさまざまなバックエンド URL を呼び出します。TargetServer 構成を使用すると、環境に依存しない TargetEndpoint 構成を作成できます。詳細については、次をご覧ください。
- バックエンド サーバー間の負荷分散（クラウド開発）
- ターゲット サーバーの構成（ローカル開発）
- ServiceCallout ターゲット: テスト環境で ServiceCallout がデモサービスを使用する場合など、環境に応じて ServiceCallout が異なるターゲットを使用することがあります。Service Callout ポリシーをご覧ください。
API プロキシ構成が環境に依存しないようにするために、条件文を使用することもできます。
environment.name 変数を使用して作成した条件ステートメントを使用すると、ポリシーの適用前に、またはバックエンドで URL にルーティングする前に現在の環境を評価できます。詳細については、フロー変数を使用した条件をご覧ください。