Apigee Enterprise API enables developers to create, modify, deploy, and debug the behavior of APIs.
APIs and API proxies
To get the hang of the Apigee Enterprise API, it's important to understand APIs and API proxies.
In Apigee, an API facade is a management construct. You use APigee to provision and configure an API. Then you manage and monitor that API. You script, apply policies to, and configure your API to modify its behavior and to monitor its usage and performance. To do this, you use Apigee to collect analytics on your API, create API products, and provision access to apps and developers.
The behavior or an API facade is implemented in an API proxy. An API proxy defines the configuration and code for the processing flow that you define for managing your API.
Apigee gives you the flexbility to do this via a UI or an API. Using the Apigee API, you can create API proxies remotely, you can download API proxies generated by Apigee, or you can import API proxies that you build from scratch. This is useful if you want to, for example, edit the API proxy configurations locally, in your favorite editor, and then import the API proxy into Apigee for deployment and testing.
Apigee defines a flow processing model that determines how request and response flows are managed. The flow is the primary construct within an API proxy.
An API proxy is a bundle of configurations (and sometimes your scripts and code) that define the behavior of those flows, and by extension the behavior of your API. API proxies are responsible for routing, transforming, securing, and otherwise treating the requests issued by apps to your API, and the responses that flow back to those apps.
An API proxy consists of:
Flows: The sequence of processing steps and policies to execute for the request/response flow.
Policy Steps: The policy configurations to be executed.
Endpoints: Every API proxy must define a proxy endpoint and a target endpointâthe entry and exit points for app requests and responses.
Resources: Not to be confused with RESTful resources, these are JavaScript scripts, Python scripts, or XSLT files that may be attached to the flow as part of a policy processing step.
Versions and Revisions
Because each API proxy is a bundle of code and configuration, Apigee needs to keep track of the update history for each package. When you add or remove a policy, for example, Apigee needs to update the API proxy without necessarily modifying the API signature as exposed to developers.
Version describes an API Interface versions, for example api.company.com/v1 and api.company.com/v2.
We use the term revision to describe API proxies. For any given API you might find yourself working with api.company.com/v2, implemented in revision 4 of the API proxy.
This becomes important as you deploy and update your changes. For any given API, you will have multiple revisions, each of which can be deployed to the test or prod environments.
Deployments and environments
API proxies always execute in the context of an environment. In fact, until you deploy the API proxy, your API won't be accessible through Apigee Enterprise. Every organization in Apigee is provided with two environments, with the default names test and prod.
You can specify which revision of an API proxy is deployed in an environment. In a simple scenario, you might have revision 10 of API proxy running in the prod environment while you work on revision 11 of the API proxy in the test environment.
By default, the latest revision is deployed. However, you can at any time deploy any revision to either environment. Usually, you will want to establish a procedure for deploying revisions, which may involve regression testing, approvals checklists, and so on.
Back
