Apigee Edge enables you to expose APIs that can be easily consumed by developers who build apps. You expose APIs on Apigee Edge by building API proxies that act as managed 'facades' for backend services. This topic discusses the relationship between APIs and API proxies on Apigee Edge.
An API is a technology 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 Edge enables you to build APIs and if you have APIs already, expose them directly, while adding a management and visibility layer. If you have HTTP enabled services, such as SOA-based Web services, they can also be exposed as APIs via Apigee Edge.
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.
API proxies manage request and response messages using a 'pipeline' processing model that defines 'Flows'. To customize the behavior of your API, you attach Policies to request and response Flows.
In an API proxy configuration, there are two types of endpoints:
- ProxyEndpoint: This configuration manages interactions with apps that consume your API. You configure the ProxyEndpoint to define the URL of your API. You usually attach Policies to the ProxyEndpoint to enforce security, quota checks, and other types of access control and rate-limiting.
- TargetEndpoint: This configuration manages interactions with your backend services on behalf of consumer apps. You configure the TargetEndpoint to forward request messages to the proper backend service. You usually attach Policies to the TargetEndpoint to ensure that response messages are properly formatted for the app that made the initial request.
You can visualize API proxies as shown by the graphic below. A basic request and response exchange between an app (HTTP client) and a backend service is managed in an API proxy by a ProxyEndpoint and TargetEndpoint.
API proxy configuration elements are comprehensively documented in the API proxy configuration reference. You don't need to undertand all of the complexities of the API proxy configuration just yet. As you walk through the topics beginning with Build a simple API proxy, you will learn about the various configuration elements in the context of implementing a fully-featured API proxy.
You can build API proxies using the Apigee Edge management UI. You can also implement API proxies on your local machine, and then import them to your organization on Apigee Edge. For an overview of the UI and API, see Using the Apigee Edge development environment.
A great way to learn about API proxies is to work with samples. For working examples refer to the API Platform samples on Github.
Help or comments?
- Something's not working: See Apigee Support.
- Something's wrong with the docs: Click Send Feedback in the lower right.
(Incorrect? Unclear? Broken link? Typo?)