모든 애플리케이션에서 데이터는 조건 로직으로 안내되어 애플리케이션을 통해 이동합니다. Apigee에서 처리 경로는 흐름으로 구성됩니다. 흐름은 API 프록시의 처리 경로를 구성하는 단계입니다. 흐름은 Apigee가 클라이언트에서 백엔드 리소스로, 다시 클라이언트에 이르는 특정 위치의 로직과 동작을 적용할 수 있도록 사용자에게 장소를 제공하는 방식입니다.
대부분의 프로그래밍 언어와 마찬가지로 API 프록시에서는 코드를 조건부로 실행할 수 있습니다.
조건은 보통 API 프록시 상태 기반이며 흐름 변수를 통해 액세스할 수 있습니다. 예를 들어 사용자 에이전트를 확인한 다음 그에 따라 요청을 처리하는 조건이 있을 수 있습니다.
API 프록시에 추가하는 대부분의 로직은 정책으로 패키징됩니다. 정책은 보안 또는 트래픽 관리와 같은 기능 영역의 로직을 캡슐화하는 Apigee 구성요소입니다.
기본 논리의 속성을 설정하는 정책을 XML로 구성합니다. 흐름 내에서 "단계" 시퀀스로 정책을 정렬하여 API 프록시가 프록시 목표에 가장 적합한 순서로 로직을 실행하도록 합니다.
API 프록시에 코드의 다른 위치(예: 다른 API 프록시)에서 사용될 로직이 포함된 경우 여러 위치에서 호출에 대한 로직을 수집할 수 있습니다. 예를 들어 다른 API 프록시에서 호출하는 공유 흐름에 보안 로직을 그룹화하여 API 프록시 간의 중복을 줄일 수 있습니다.
Apigee에는 디버깅 및 테스트를 수행할 때 API 프록시의 실행 흐름을 검사하기 위해 사용할 수 있는 디버그 도구가 포함되어 있습니다. 이 도구는 요청에 대해 실행되는 각 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)."]]
