There are several concepts that are common ideas with a unique meaning in Apigee.
| Term | Definition |
|---|---|
| API | A proxy that acts as a facade for your existing API. Rather than calling your existing API, developers begin calling the new API generated by Apigee. This facade decouples your public interface from your backend API, shielding developers from backend changes, while enabling you to innovate at the edge without impacting your internal development teams. As you make backend changes, developers continue to call the same API uninterrupted. In more advanced scenarios, Apigee lets you expose multiple interfaces to the same API, freeing you to customize the signature of an API to meet the needs of various developer niches simultaneously. |
| API base path and resources | An API is made up of base path and a set of resources (also known as resource paths). For each API, you define a single root URL and multiple resource paths. You can think of an API simply as a set of URIs, all of which share a common base path. To make it easier to manage your APIs, Apigee augments these raw URIs with display names and descriptions. |
| API product | A collection of API resources (URIs) combined with a service plan and presented to developers as a bundle. The API product can also include some metadata specific to your business for monitoring or analytics. |
| Apps | Your developers use apps to access the resources in your API products. When you create an app, you select the API product to include, and Apigee generates a key. Each app has a single key that provides access to multiple API products. Apps allow you to control who can access your resources. You can control who has access to your API products by revoking and refreshing an app's key. And you can control access to bundles of resources by revoking or deleting access to the products in an app. |
| Environment | A runtime execution context for APIs. An API must be deployed to an environment before it can be accessed at runtime. By default, Apigee organizations are provisioned with two environments: 'test' and 'prod'. The 'test' environment is typically used for deploying APIs undergoing testing. The 'prod' environment is typically used for deploying APIs for production use. |
| Organization | A container for all the objects in your Apigee account, including APIs, API products, apps, and developers. A user account is required for each organization for which you may be a member. (Most users will have an account in only one organization.) You need to supply your credentials (username and password) and the name of your organization with each API request you submit. |
| Policy | A processing step that executes as an atomic, reusable unit of logic within an API flow. Typical policies include routing requests to the proper endpoint, transforming a message format, enforcing access control, calling remote services for additional information, masking sensitive data from external users, examining message contents for potential threats, caching common responses to improve performance, and so on. Policies may be conditionally executed based on the content or context of a request or response message. For example, a transformation policy may be executed to customize a response format if the request message was sent from a smartphone. |
| Resource | The basis of the RESTful architecture, a resource is a network-accessible entity. Example resources include the Twitter timeline, Google Maps image tiles, Facebook posts, etc. Think of this as the R in URL. |
| Resource path |
A RESTful concept, a resource path is a uniform resource identified (URI) that identifies the network path to a given resource. |
| Version | The version of the developer-facing API interface. For example, pivotaltracker.com/services/v3, or api.enterprise.apigee.com/v1. (This term is distinguished from ‘revision’, which is the numbered, version-controlled package of configuration and policies bundled into an API Proxy. In short, API interfaces have versions, while API Proxies have revisions. |
