このページは 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 Integration のテスト環境と本番環境にデプロイします。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 は、環境に応じて異なるターゲットを使用することがあります。ServiceCallout ポリシーをご覧ください。
API プロキシ構成が環境に依存しないようにするために、条件文を使用することもできます。environment.name 変数を使用して作成した条件ステートメントを使用すると、ポリシーの適用前か、バックエンドで URL にルーティングする前に現在の環境を評価できます。詳細については、フロー変数での条件をご覧ください。