Apigee 可讓您輕鬆快速地建構符合 REST 樣式的 API，供應用程式開發人員使用。您可以在 Apigee 上公開 API，方法是建構 API Proxy，做為後端服務的受管理「操作介面」。本主題將說明 Apigee 上的 API 與 API Proxy 之間的關係。
影片：觀看這部短片，瞭解 API Proxy 簡介。
什麼是 API？
API 是一種介面，可讓一個應用程式輕鬆取用另一個應用程式的功能或資料。API 可定義應用程式邏輯和資料的簡化穩定進入點，方便開發人員存取及重複使用其他開發人員建構的應用程式邏輯。如果是網路 API，該邏輯和資料會透過網路公開。
由於使用 API 的應用程式對變更很敏感，因此 API 也代表合約。這份合約可確保 API 在一段時間內會以可預測的方式變更。
Apigee 可讓您建構 API，如果已有 API，則可直接公開，同時新增管理和瀏覽層。如果您有啟用 HTTP 的服務 (例如以 SOA 為基礎的 Web 服務)，也可以透過 Apigee 將這些服務公開為 API。
您也可以透過 Apigee 建立 API，方法是實作 API 服務平台代管的應用程式，不需涉及後端服務。您可以使用 JavaScript 和 Java 建構這些應用程式。
什麼是 API Proxy？
您可以在 Apigee 上實作 API Proxy，藉此公開 API。API Proxy 會將應用程式導向的 API 與後端服務分離，並防止這些應用程式免於後端程式碼變更。當您對服務進行後端變更時，應用程式會繼續呼叫相同的 API，不會中斷。
在 API Proxy 設定中，端點分為兩種：
ProxyEndpoint：定義用戶端應用程式使用 API 的方式。您可以設定 ProxyEndpoint，定義 API Proxy 的網址。Proxy 端點也會決定應用程式是透過 HTTP 還是 HTTPS 存取 API Proxy。您通常會將政策附加至 ProxyEndpoint，以強制執行安全性、配額檢查，以及其他類型的存取權控管和速率限制。
TargetEndpoint：定義 API Proxy 與後端服務的互動方式。您可以設定 TargetEndpoint，將要求轉送至適當的後端服務，包括定義任何安全性設定、HTTP 或 HTTPS 通訊協定，以及其他連線資訊。您可以將政策附加至 TargetEndpoint，確保回應訊息的格式符合提出初始要求的應用程式。
您可以將 API Proxy 視覺化，如下圖所示：
API Proxy 類型
Apigee 支援兩種 Proxy 類型：
標準 Proxy 僅包含標準政策。標準 Proxy 適用於輕量級 API 解決方案，且無法納入 API 產品。
API Proxy 修訂版本提供輕量機制，可讓您在疊代時管理 API Proxy 設定的更新。修訂版本會依序編號，因此您可以部署 API Proxy 的先前修訂版本，藉此還原變更。您可以透過修訂版本將 API Proxy 部署至正式環境，同時在測試環境中繼續建立該 API Proxy 的新修訂版本。準備就緒後，即可將 API 代理的較高修訂版本從測試升級至正式版。
什麼是政策？
Apigee 可讓您使用政策控管 API 行為，完全不需要編寫程式碼。政策就像模組，可在 Proxy 要求/回應流程中實作特定且有限的管理功能。政策的設計宗旨，是讓您輕鬆且可靠地為 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"]],["上次更新時間：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)"]]
