API プロキシに追加するロジックの多くは、ポリシーとしてパッケージ化されています。ポリシーは、セキュリティやトラフィック管理などの機能領域のロジックをカプセル化した Apigee コンポーネントです。ポリシーは、基になるロジックのプロパティを設定した XML によって構成します。フロー内の一連の「ステップ」にポリシーを配置して、API プロキシがプロキシの目的に最も適した順序でロジックを実行できるようにします。
コード内の複数の場所（他の API プロキシなど）で使用されるロジックが API プロキシに組み込まれている場合、そのロジックを 1 か所にまとめて複数の場所から呼び出せるようにすることができます。たとえば、他の API プロキシが呼び出す共有フロー内でセキュリティ ロジックをグループ化して、API プロキシ間の重複を減らすことができます。
Apigee には、デバッグおよびテスト時に API プロキシの実行フローの検査に使用できる Debug ツールが用意されています。このツールは、リクエストに対して実行される各 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"]],["最終更新日 2025-08-18 UTC。"],[[["\u003cp\u003eAPI proxies are implemented in Apigee by configuring logic as a sequence of steps executed in response to client requests, effectively serving as the API from the client's perspective.\u003c/p\u003e\n"],["\u003cp\u003eFlows in Apigee define the processing path for API proxies, allowing for the application of logic and behavior at specific points in the client-to-backend interaction.\u003c/p\u003e\n"],["\u003cp\u003eAPI proxies in Apigee access and manipulate execution state through flow variables, which can be system-defined or custom-created, and are accessible in XML, Java, JavaScript, or Python.\u003c/p\u003e\n"],["\u003cp\u003eConditional logic can be implemented within API proxies, enabling code to execute based on the proxy's state, often accessed through flow variables.\u003c/p\u003e\n"],["\u003cp\u003eMost of the logic implemented in an API proxy is managed through policies, which are components encapsulating functional areas like security or traffic management, arranged in flows for execution.\u003c/p\u003e\n"]]],[],null,["# Key points of API proxy development\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\nThis topic lists some basic characteristics of API proxies, along with links to more\ninformation.\n\nAPIs are entry points for one application to use the capabilities of another. You implement API\nproxies to create APIs\n----------------------------------------------------------------------------------------------------------------------\n\nIn Apigee, you implement API proxies by configuring API proxy logic as a sequence of\nsteps that execute in response to a request from client code. You expose an API proxy to clients\nby defining endpoints that include a URL with resource paths, an HTTP verb, body requirements,\nand so on.\n\nThough it's called an API proxy, from the client code's perspective, *it's the\nAPI*.\n\nFor an overview of API proxies, see [Understanding APIs and API\nproxies](/apigee/docs/api-platform/fundamentals/understanding-apis-and-api-proxies).\n\nYou arrange the sequence of API proxy\nlogic using flows\n-------------------------------------------------------\n\nIn any application, data flows through the application guided by condition logic. In Apigee,\nthe path of processing is made up of flows. A flow is a sequence of stages (or \"steps\")\nthat make up an API proxy's processing path. Flows are how Apigee provides places for you\nto apply logic and behavior at specific places from client to backend resource, then back to\nclient.\n\nFor more on flows, see [Controlling\nhow a proxy executes with flows](/apigee/docs/api-platform/fundamentals/what-are-flows)\n\nYou access state data through\nflow variables created by API proxies\n-------------------------------------------------------------------\n\nAn API proxy has access to variables that represent execution state. You can access these\nvariables from the XML that configures your API proxies and policies. You can also access them\nwhen you're extending an API proxy with a procedural language, such as Java, JavaScript, or\nPython.\n\nThese variables are held by Apigee. Some exist by default, usually because they're common\nto what API proxies do (such as because they're part of an HTTP request). You can also create\nyour own variables to satisfy a logic requirement.\n\nFor more about variables, see [Managing proxy state with flow\nvariables](/apigee/docs/api-platform/fundamentals/introduction-flow-variables).\n\nYou can have API proxies execute\nconditionally\n----------------------------------------------\n\nJust as in most programming languages, in API proxies you can have code execute conditionally.\nConditions are often based on API proxy state, which you can access through flow variables. For\nexample, you can have a condition that checks for the user agent, then processes the request\naccordingly.\n\nFor more on conditional execution, see\n[Conditions with\nflow variables](/apigee/docs/api-platform/fundamentals/flow-variables-and-conditions).\n\nYou implement most logic in an API proxy\nusing policies\n-------------------------------------------------------\n\nMost of the logic you add to an API proxy is packaged as policies. A policy is an Apigee\ncomponent that encapsulates logic for a functional area, such as security or traffic management.\nYou configure a policy with XML that sets properties for the underlying logic. You arrange\npolicies in a sequence of \"steps\" within a flow, so that your API proxy executes the logic in the\nbest order for your proxy's goals.\n\nFor more about policies, see [What's a policy?](/apigee/docs/api-platform/develop/policy-attachment-and-enforcement).\n\nYou can include reusable sets of\nfunctionality\n----------------------------------------------\n\nWhen your API proxy includes logic that will be used from multiple places in your code---such\nas other API proxies---you can collect that logic for calls from multiple places. For example,\nyou can group security logic in a shared flow that other API proxies call, reducing duplication\nacross API proxies.\n\nFor more on shared flows, see [Reusable\nshared flows](/apigee/docs/api-platform/fundamentals/shared-flows). For more on API proxy chaining, see [Chaining API proxies\ntogether](/apigee/docs/api-platform/fundamentals/connecting-proxies-other-proxies).\n\nYou can debug a proxy with the Debug tool\n-----------------------------------------\n\nApigee includes a [Debug tool](/apigee/docs/api-platform/debug/trace-overview) you can use to examine your API proxy's execution\nflow when\ndebugging and testing. The tool visually presents each API proxy step that executes for a\nrequest. As in a debugger, at each step you can view the list of variable values that make up API\nproxy state.\n\nFor more about debugging with the Debug tool, see [Debug tool](/apigee/docs/api-platform/debug/trace-overview).\n\nYou handle API proxy errors as faults\n-------------------------------------\n\nBy configuring a fault handler, you can customize the error returned to an API client. Fault\nhandlers give you control over error messages whether the error originates from your own code or\nfrom an included component (such as a policy).\n\nFor more, see [Handling\nfaults](/apigee/docs/api-platform/fundamentals/fault-handling)."]]
