借助 Apigee，您可以轻松、快速构建可供应用开发者使用的 RESTful API。通过构建充当后端服务托管“Facade”的 API 代理，可在 Apigee 上公开 API。本主题讨论 Apigee 上 API 与 API 代理之间的关系。
视频：观看此视频短片，了解 API 代理。
什么是 API？
API 是可以让一个应用轻松使用来自另一个应用的功能或数据的接口。通过定义稳定且简化的应用逻辑和数据入口点，API 可让开发者轻松访问和重复使用其他开发者构建的应用逻辑。对于 Web API，该逻辑和数据会通过网络公开。
由于使用 API 的应用对更改很敏感，因此 API 还暗含合同。此合同提供一定程度的保证，即随着时间的推移，API 会以可预测的方式发生变化。
借助 Apigee，您可以构建 API；如果您已经拥有 API，则直接公开这些 API，同时添加管理和可见性层。如果您有启用 HTTP 的服务（例如基于 SOA 的网络服务），则这些服务也可以通过 Apigee 作为 API 公开。
此外，借助 Apigee，您还可实现 API 服务平台上托管的应用，而无需相关后端服务，从而构建 API。您可以使用 JavaScript 和 Java 构建这些应用。
什么是 API 代理？
您可以通过实现 API 代理在 Apigee 上公开 API。API 代理将面向应用的 API 与后端服务分离，从而保护这些应用免受后端代码更改的影响。当您对服务进行后端更改时，应用会继续调用相同的 API，而不会中断。
API 代理配置中有两种类型的端点：
ProxyEndpoint：定义客户端应用使用您的 API 的方式。您可配置 ProxyEndpoint 来定义 API 代理的网址。代理端点还确定应用是通过 HTTP 还是 HTTPS 访问 API 代理。通常情况下，您可以将政策附加到 ProxyEndpoint 以强制执行安全性、配额检查，以及其他类型的访问权限控制和速率限制。
TargetEndpoint：定义 API 代理与后端服务互动的方式。您可配置 TargetEndpoint 以将请求转发到正确的后端服务，包括定义任何安全设置、HTTP 或 HTTPS 协议以及其他连接信息。您可以将政策附加到 TargetEndpoint，以确保针对发出初始请求的应用设置正确的响应消息格式。
API 代理修订版本提供了一种轻量级机制，用于在迭代时管理 API 代理配置的更新。系统会依序对修订版本进行编号，以便您可通过部署先前 API 代理的修订版本来还原更改。通过修订版本，您可以将 API 代理部署到生产环境中，同时继续在测试环境中创建该 API 代理的新修订版本。准备就绪后，您可以将 API 代理的更高修订版本从测试提升为生产。
什么是政策？
借助 Apigee，您可以使用政策控制 API 行为，而无需编写任何代码。在代理请求/响应流中，政策就像一个实现特定受限管理功能的模块。这些政策旨在让您能够轻松可靠地向 API 添加常见的管理功能类型。政策提供安全、速率限制、转换和中介功能等功能，让您无需自行编写代码和维护此功能。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-04。"],[[["\u003cp\u003eApigee enables the creation of RESTful APIs and API proxies, which act as managed facades for backend services, allowing applications to consume capabilities or data from other applications.\u003c/p\u003e\n"],["\u003cp\u003eAPI proxies decouple the app-facing API from backend services, shielding apps from backend code changes through two endpoints: ProxyEndpoint for client app interaction and TargetEndpoint for backend service interaction.\u003c/p\u003e\n"],["\u003cp\u003eApigee supports standard and extensible proxies, with extensible proxies offering greater functionality through the inclusion of extensible policies or flow hooks.\u003c/p\u003e\n"],["\u003cp\u003eAPI proxy revisions provide a way to manage updates to the proxy configuration, enabling the ability to revert changes or promote higher revisions from test to production environments.\u003c/p\u003e\n"],["\u003cp\u003ePolicies in Apigee are modules that implement specific management functions within the proxy request/response flow, offering features like security, rate-limiting, transformation, and mediation without requiring custom code.\u003c/p\u003e\n"]]],[],null,["# Understanding APIs and API proxies\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\nApigee lets you easily and quickly build RESTful APIs that can be consumed by app\ndevelopers. You expose APIs on Apigee by building API proxies that act as managed 'facades' for\nbackend services. This topic discusses the relationship between APIs and API proxies on Apigee. \n**Video:** Check out this short video for an introduction to API\nproxies.\n\nWhat is an API?\n---------------\n\nAn API is an interface that makes it easy for one application to *consume* capabilities or\ndata from another application. By defining stable, simplified entry points to application logic\nand data, APIs enable developers to easily access and reuse application logic built by other\ndevelopers. In the case of *Web APIs*, that logic and data is exposed over the network.\n\nSince applications that consume APIs are sensitive to changes, APIs also imply a *contract*.\nThe contract provides some level of assurance that, over time, the API will change in a\npredictable manner.\n\nApigee enables you to build APIs and if you have APIs already, expose them directly,\nwhile adding a management and visibility layer. If you have HTTP enabled services, such as\nSOA-based Web services, they can also be exposed as APIs via Apigee.\n\nApigee also enables you to build APIs by implementing applications hosted on the API Services\nplatform---with no backend service involved. You can build these applications in JavaScript and\nJava.\n| **Best practice:** Apigee provides a wealth of information about APIs and best practices for developing and consuming them. To get started, see the [How to design APIs that developers love](https://www.youtube.com/watch?v=kgIq02wP73s) or download the free eBook [Web API Design: The Missing Link](/static/files/apigee/apigee-web-api-design-the-missing-link-ebook.pdf).\n\nWhat is an API proxy?\n---------------------\n\nYou expose APIs on Apigee by implementing *API proxies*. API proxies decouple the\napp-facing API from your backend services, shielding those apps from backend code\nchanges. As you make backend changes to your services, apps continue to call the same API\nwithout any interruption.\n\nIn an API proxy configuration, there are two types of endpoints:\n\n- **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.\n- **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.\n\nYou can visualize API proxies as shown by the graphic below:\n\nAPI proxy types\n---------------\n\nApigee supports two proxy types:\n\n- **Standard proxies** include only [standard policies](/apigee/docs/api-platform/reference/policies/reference-overview-policy#policy-types). Standard proxies are suitable for lightweight API solutions and cannot be included in [API products](/apigee/docs/api-platform/publish/what-api-product#limitations).\n- **Extensible proxies** include at least one [extensible policy](/apigee/docs/api-platform/reference/policies/reference-overview-policy#policy-types) or flow hook. Extensible proxies can include much more functionality than standard proxies.\n\nHow do you create an API proxy?\n-------------------------------\n\nAn API proxy consists of a bundle of XML configuration files and code (such as JavaScript and\nJava). Apigee provides several ways for you to create API proxies, including:\n\n- Using the [Apigee UI](https://apigee.google.com) to define an API proxy in a Graphical User Interface (GUI). For more, see [Build a simple\n API proxy](/apigee/docs/api-platform/fundamentals/build-simple-api-proxy).\n- Creating XML files, along with any other supporting files, that define your API proxy and then importing them into Apigee.\n- Using the [Apigee API](/apigee/docs/reference/apis/apigee/rest) to create your API proxies by making a series of REST requests to Apigee.\n- Develop locally using Apigee in VS Code and deploy as an archive. For more information, see [Overview of local development with Apigee](/apigee/docs/api-platform/local-development/overview)\n\nWhat is an API proxy revision?\n------------------------------\n\n| **Warning:** Don't confuse the version of an API (that is, the public interface) with the *revision* of an API proxy (that is, the internal number associated with a configuration). The two numbers are unrelated, and the revision number of an API proxy is totally opaque to apps that consume your API.\n\nAPI proxy revisions provide a lightweight mechanism for managing the updates to the API proxy\nconfiguration as you iterate. Revisions are sequentially numbered, enabling you to revert a change\nby deploying a previous revision of your API proxy. Revisions let you deploy an API proxy\ninto a production environment while continuing to create new revisions of that API proxy in a\ntest environment. When you are ready, you can *promote* the higher revision of your API\nproxy from test to prod.\n\nWhat is a policy?\n-----------------\n\nApigee enables you to control API behavior without writing any code by using\n[policies](/apigee/docs/api-platform/reference/policies/reference-overview-policy).\nA policy is like a module that implements a specific, limited management function as part of the\nproxy request/response flow. Policies are designed to let you add common types of management\ncapabilities to an API easily and reliably. Policies provide features like security,\nrate-limiting, transformation, and mediation capabilities, saving you from having to code and\nmaintain this functionality on your own.\n\nCreate your first API proxy\n---------------------------\n\nApigee provides a set of tutorials that you can use to create your first API. Start with the\n[Build your first API proxy](/apigee/docs/api-platform/get-started/get-started). See also other [Get started topics](/apigee/docs/getstarted).\n\nLearn more\n----------\n\n- [API proxy configuration reference](/apigee/docs/api-platform/reference/api-proxy-configuration-reference)\n- [API development\n lifecycle](/apigee/docs/api-platform/fundamentals/api-development-lifecycle)\n- [Key points of API\n proxy development](/apigee/docs/api-platform/fundamentals/structure-api-proxies)"]]
