Understanding APIs and API proxies
Apigee Edge lets you easily and quickly build RESTful APIs that can be consumed by app developers. You expose APIs on 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.
Video: Check out this short video for an introduction to API proxies.
An API 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 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.
You expose APIs on Apigee Edge by implementing API proxies. API proxies decouple the app-facing API from your backend services, shielding those apps from backend code changes. As you make backend changes to your services, apps continue to call the same API without any interruption.
In an API proxy configuration, there are two types of endpoints:
- ProxyEndpoint: Defines the way client apps consume your APIs. You configure the ProxyEndpoint to define the URL of your API proxy. The proxy endpoint also determines whether apps access the API proxy over HTTP or HTTPS. You usually attach policies to the ProxyEndpoint to enforce security, quota checks, and other types of access control and rate-limiting.
- TargetEndpoint: Defines the way the API proxy interacts with your backend services. You configure the TargetEndpoint to forward requests to the proper backend service, including defining any security settings, HTTP or HTTPS protocol, and other connection information. You can 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:
- Using the Edge management UI to define an API proxy in a Graphical User Interface (GUI). For more, see Build a simple API proxy.
- Creating XML files, along with any other supporting files, that define your API proxy and then importing them into Edge.
- Using the Edge management API to create your API proxies by making a series of REST requests to Edge.
- Deploy a Node.js application as a proxy. See Deploying a standalone Node.js app.
Edge enables you to control API behavior without writing any code by using policies. A policy is like a module that implements a specific, limited management function as part of the proxy request/response flow. 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.
Apigee provides a set of tutorials that you can use to create your first API:
- Build an API proxy using the Apigee Edge management UI as described in Create your first API proxy.
- Build an API proxy as a set of XML files as described in Part 1: Create your API in XML.
A great way to learn about API proxies is to work with the samples as described in Using the sample API proxies.
Help or comments?
- If something's not working: Ask the Apigee Community or see Apigee Support.
- If something's wrong with the docs: Send Docs Feedback
(Incorrect? Unclear? Broken link? Typo?)