API development lifecycle

This page applies to Apigee and Apigee hybrid.

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 deployment types in an environment:

Type Description
Proxy 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 Develop and test your programmable API proxies using Apigee in VS Code.

Adding policies

Apigee enables you to program API behavior without writing any code, by using policies. A policy is like a module that implements a specific, limited management function. Policies are designed to let you add common types of management capabilities to an API easily and reliably. Policies provide features like security, rate-limiting, transformation, and mediation capabilities, saving you from having to code and maintain this functionality on your own. You can also write custom scripts and code (such as JavaScript applications), that extend API proxy functionality and enable you to innovate on top of the basic management capabilities supported by Apigee policies. For more information about Apigee policies, see What's a policy?

Apigee provides ready to use polices for various features such as traffic management, security, mediation, and extension policies. To view the complete list of policies available in Apigee, see Policy reference overview.

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 test and production 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.