ProxyEndpoint 구성은 클라이언트 앱이 Apigee를 통해 API를 사용하는 방법을 정의합니다.
ProxyEndpoint는 API 프록시의 URL과 프록시 작동 방식을 정의합니다. 여기서 적용할 정책, 라우팅할 대상 엔드포인트, 이러한 정책 또는 라우팅 규칙을 실행하기 위해 충족해야 하는 조건 등이 정의됩니다.
간단히 말해 ProxyEndpoint 구성은 API 구현을 위해 수행해야 하는 모든 것을 정의합니다.
안티패턴
API 프록시에는 하나 이상의 프록시 엔드포인트가 있을 수 있습니다. 여러 ProxyEndpoint를 정의하는 것은 단일 프록시에서 여러 API를 구현하기 위한 쉽고 간단한 메커니즘입니다. 이렇게 하면 TargetEndpoint 호출 전 후에 정책 또는 비즈니스 로직을 재사용할 수 있습니다.
반면 단일 API 프록시에서 여러 ProxyEndpoint를 정의하면 관련 없는 API 여러 개가 단일 아티팩트로 개념적으로 결합됩니다. 이는 API 프록시의 읽기, 이해, 디버그, 유지관리를 어렵게 합니다. 이로 인해 API 프록시의 기본 철학이 사라지기 때문에 개발자가 API를 손쉽게 만들고 유지관리할 수 있습니다.
영향
한 API 프록시의 여러 ProxyEndpoint는 다음을 야기할 수 있습니다.
개발자가 API 프록시를 이해하고 유지관리하기 어려워집니다.
분석이 난독화됩니다. 기본적으로 분석 데이터는 프록시 수준에서 집계됩니다. 커스텀 보고서를 만들지 않으면 프록시 엔드포인트로 측정항목을 분석하지 않습니다.
API 프록시의 문제를 해결하기 어려워집니다.
권장사항
새로운 API 프록시를 구현하거나 기존 API 프록시를 다시 설계할 때 다음 권장사항을 따르세요.
단일 ProxyEndpoint로 API 프록시 1개를 구현합니다.
공통 대상 서버를 공유하는 API가 여러 개 있거나 대상 서버 호출 전 또는 호출 후 동일한 로직이 필요한 경우 공유 흐름을 사용하여 여러 API 프록시에서 로직을 구현하는 것이 좋습니다.
공통 시작 기본 경로를 공유하지만 서픽스가 다른 API가 여러 개 있는 경우 단일 ProxyEndpoint에서 조건부 흐름을 사용합니다.
여러 ProxyEndpoint가 있는 API 프록시가 있고 문제가 없다면 아무런 조치를 취하지 않아도 됩니다.
API 프록시당 하나의 ProxyEndpoint를 사용하면 다음과 같이 됩니다.
더욱 간편하고 쉬운 프록시 유지관리
모든 ProxyEndpoint에 롤업되는 대신 별도로 보고되는 애널리틱스의 더 나은 정보(프록시 성능, 목표 응답 시간 등)
[[["이해하기 쉬움","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(UTC)"],[[["\u003cp\u003eApigee ProxyEndpoints define how client apps interact with APIs, including URL, behavior, policies, target routing, and execution conditions.\u003c/p\u003e\n"],["\u003cp\u003eWhile defining multiple ProxyEndpoints in a single API proxy can implement multiple APIs, it can also lead to complexity, making the API proxy harder to understand, debug, and maintain.\u003c/p\u003e\n"],["\u003cp\u003eMultiple ProxyEndpoints obfuscate analytics data, making it harder to break down metrics by proxy endpoint without custom reports and making troubleshooting more difficult.\u003c/p\u003e\n"],["\u003cp\u003eThe best practice is to use one API proxy with a single ProxyEndpoint to promote easier maintenance, clearer analytics, and faster troubleshooting.\u003c/p\u003e\n"],["\u003cp\u003eShared flows can implement common logic across multiple APIs, while conditional flows can handle multiple APIs sharing a base path within a single ProxyEndpoint.\u003c/p\u003e\n"]]],[],null,["# Antipattern: Define multiple ProxyEndpoints in an API proxy\n\n*You're viewing **Apigee** and **Apigee hybrid** documentation.\nView [Apigee Edge](https://docs.apigee.com/api-platform/antipatterns/multiple-proxyendpoints) documentation.*\n\nThe ProxyEndpoint configuration defines the way client apps consume the APIs through Apigee.\nThe ProxyEndpoint defines the URL of the API proxy and how a proxy behaves: which policies to apply\nand which target endpoints to route to, and the conditions that need to be met for these policies or\nroute rules to be executed.\n\nIn short, the ProxyEndpoint configuration defines all that needs to be done to implement an\nAPI.\n\nAntipattern\n-----------\n\nAn API proxy can have one or more proxy endpoints. Defining multiple ProxyEndpoints is an easy\nand simple mechanism to implement multiple APIs in a single proxy. This lets you reuse policies\nand/or business logic before and after the invocation of a TargetEndpoint.\n\nOn the other hand, when defining multiple ProxyEndpoints in a single API proxy, you end up\nconceptually combining many unrelated APIs into a single artifact. It makes the API proxies harder\nto read, understand, debug, and maintain. This defeats the main philosophy of API proxies: making\nit easy for developers to create and maintain APIs.\n\nImpact\n------\n\nMultiple ProxyEndpoints in an API proxy can:\n\n- Make it hard for developers to understand and maintain the API proxy.\n- Obfuscate analytics. By default, analytics data is aggregated at the proxy level. There is no breakdown of metrics by proxy endpoint unless you create custom reports.\n- Make it difficult to troubleshoot problems with API proxies.\n\nBest practice\n-------------\n\nWhen you are implementing a new API proxy or redesigning an existing API proxy, use the\nfollowing best practices:\n\n1. Implement one API proxy with a single ProxyEndpoint.\n2. If there are multiple APIs that share common target server and/or require the same logic pre- or post-invocation of the target server, consider using shared flows to implement such logic in different API proxies.\n3. If there are multiple APIs that share a common starting base path, but differ in the suffix, use conditional flows in a single ProxyEndpoint.\n4. If there exists an API proxy with multiple ProxyEndpoints and if there are no issues with it, then there is no need to take any action.\n\nUsing one ProxyEndpoint per API proxy leads to:\n\n1. Simpler, easier to maintain proxies\n2. Better information in Analytics, such as proxy performance and target response time, will be reported separately instead of rolled up for all ProxyEndpoints\n3. Faster troubleshooting and issue resolution\n\nFurther reading\n---------------\n\n- [API Proxy Configuration Reference](/apigee/docs/api-platform/reference/api-proxy-configuration-reference)\n- [Reusable shared flows](/apigee/docs/api-platform/fundamentals/shared-flows)"]]
