There are several concepts that are common ideas with a unique meaning in Apigee.
An 'application programming interface' is an architecture that makes it easy for one application to 'consume' capabilities or data from another application.
By defining stable, simplified entry points to application logic and data, APIs enable developers to easily access and reuse application logic built by other developers. In the case of 'Web APIs', that logic and data is exposed over the network. Since applications that consume APIs are sensitive to changes, APIs also imply a 'contract'. The contract provides some level of assurance that, over time, the API will change in a predictable manner.
Apigee provides a wealth of information about APIs and best practices for developing and consuming them. To get started, see the webcast API Design or download the free eBook Web API Design: Crafting Interfaces that Developers Love.
A facade on Edge for one or more APIs, generic HTTP services, or applications (such as Node.js).
An API proxy is implemented as a set of configuration files, policies, and code that rely on a set of resources provided by Apigee Edge. API proxies can be generated and configured using the Apigee Edge management UI, or they can be implemented locally in a text editor or IDE.
The facade provided by an API proxy decouples the developer-facing API from 'backend' services, shielding developers from code changes and enabling innovation at the edge without impacting your internal development teams. As development teams make backend changes, developers continue to call the same interface uninterrupted. Apigee enables you to 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||
APIs defined by network addresses and URIs. An API is made up of a 'base path' and a set of 'API resources'. Every API proxy defines a base path and, optionally, multiple API 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. Edge enables you to attach policies and code to URIs, enabling fine-grained control and management of the behavior of your APIs.
A collection of API resources (URIs) combined with a quota, or 'service plan', which is published to app developers at design time. API products can in turn be bundled into API packages for monetization.
An API key is bound to one or more API products, enforcing a binding between an app and the bundle of URIs that the app is permitted to consume.
|API package||A collection of API products that are presented to developers as a bundle, and typically associated with a rate plan defined in monetization.|
An abbreviation of 'application'. The term 'app' has come to refer to mobile applications that consume APIs. Developers implement apps in a variety of programming languages, and using various technologies and platforms. Developers who want to consume APIs register apps in an API provider's organization on Apigee Edge.
When the app is registered, Apigee generates an API key and secret that identify the app. The developer embeds the API key in the app, which presents the key when making requests. API Services implements security around the API key through direct API key validation or through OAuth.
A runtime execution context for API proxies. An API proxy must be deployed to an environment before the API it exposes is accessible over the network. By default, organizations are provisioned with two environments: 'test' and 'prod'.
A container for all the objects in an Apigee Edge account, including API proxies, API products, API packages, apps, and developers.
A user account is required for each organization for which you are 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.
A processing step that executes as an atomic, reusable unit of logic within an API proxy processing flow.
Typical policy-based functionality includes transforming message formats, enforcing access control, calling remote services for additional information, masking sensitive data from external users, examining message content 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.
|API resource path||A RESTful concept, a resource path is a uniform resource identifier (URI) that identifies the network path to a given resource.|
The version of the developer-facing API interface.
This term is distinguished from 'revision', which is the numbered, version-controlled package of configuration and policies bundled into an API Proxy. API interfaces have versions; API proxies have revisions.
|revision||A numbered, version-controlled package of configuration and policies bundled into an API Proxy. This term is distinguished from 'version', which is the developer-facing API interface. See version above.|