viewing Apigee X documentation.
View Apigee Edge documentation.
The following sections summarize the API development lifecycle using Apigee.
Developing API proxies
Apigee supports the following options for iterative API proxy development:
For more information about API proxies, see Understanding APIs and API proxies.
Cloud development using Apigee
Develop your API proxies using the API proxy editing and debugging tools provided with Apigee. As you work on an API proxy, Apigee saves iterations of your configuration as revisions.
When you deploy an API proxy, you choose a specific revision to deploy. Typically, you deploy the most recent revision, and, if necessary, revert to a previous revision. See Deploying API proxies.
To get started developing your API proxies using Apigee, see Building a simple API proxy.
Local development using Apigee in VS Code
Use Apigee in Visual Studio Code (VS Code) to develop your API proxies and verify the functionality through unit and manual testing (for example, send a request and view the results).
After you complete your local validation, deploy your API proxy configurations as archives to your Apigee environments. See Deploying API proxies.
To get started developing your API proxies locally using Apigee in VS Code, see Building your first API proxy using Apigee in VS Code.
Deploying API proxies
You create environments in which to deploy API proxies. The distinction between different environments is arbitrary — each environment is simply identified by a different set of network addresses (URLs). The goal is to provide you with a domain in which you can build and verify API proxies before the API is exposed to external developers. For more information, see About environments and environment groups.
By deploying your APIs to multiple environments, you can segregate traffic between the API proxies that you are working on in a test environment, and those that are being accessed by external apps at runtime in a production environment.
Apigee supports the following types of deployment environments:
|Standard||Develop and test your API proxies in your Apigee development environments, and then deploy them to Apigee integration test and production environments. See Deploying an API proxy.|
|Archive (Preview)||Develop and test your API proxies locally, using Apigee in VS Code, and then deploy an archive of your API proxy configuration environment to your Apigee integration test and production environment. See Deploying and managing archives in an Apigee environment.|
Promoting to production
You choose where to deploy an API. For instance, you can promote a revision to a production environment to allow developers to start working with your API. At the same time, you may be iterating multiple revisions in a local or test environment, where you're adding features or fine-tuning policies. Then, when you're ready, you can deploy the new revision to the production environment, overwriting the existing revision in that environment. Using this method, you can always have a live revision of your API available to developers while you're developing and testing new features.
Scripting deployment using the Apigee API
Apigee provides a RESTful API that enables you to integrate API proxy deployment and management into your organization's software development lifecycle (SDLC). For example, to ensure that security, reliability, and consistency requirements are met, a common usage of the Apigee API is to write scripts or code that programmatically deploy API proxies and promote them from one environment to another, as part of a larger automated process.
For more information, see Apigee API.
Managing environment resources
Environments provide segregation of data and resources. You can, for example, set up different caches in your
environments that can be accessed only by API proxies executing in that environment. Additionally, API keys that are issued in a test environment are not valid in a production environment, and vice-versa.
For additional control during promotion, it is recommended that you only iterate on API proxies in a test environment, and make as few changes as necessary to API proxies deployed in a production environment.
To do so, you need to ensure that certain resources associated with each environment are configured in such a way that they can remain static in an API proxy configuration.
- Key value maps (KVMs): If scoped to the environment, you should ensure that naming conventions are used to enable API proxies to store data without requiring configuration changes during promotion. For more information, see Using key value maps.
- Target URLs: It is common for API proxies to call different backend URLs during testing and production. You can use TargetServer configurations to create environment-independent TargetEndpoint configurations. For more information, see
- ServiceCallout targets: Service callouts may use different targets depending on the environment, if, for example, a ServiceCallout in the test environment consumes a demo service. See ServiceCallout policy.
To make API proxy configurations environment-independent, you can also use conditional statements.
Conditional statements built with the
environment.name variable can be used to evaluate the
current environment before enforcing a policy or before routing to a URL on the backend. For more information,
see Conditions with flow variables.