코드 흐름의 고유한 단점이 있는 이유를 이해하려면 아래 다이어그램에 나와 있는 것처럼 요청이 라우팅되는 경로를 파악해야 합니다.
그림 1: 코드 흐름
다이어그램에서 볼 수 있듯이 요청은 라우터와 메시지 프로세서를 비롯한 여러 분산 구성요소를 통과합니다.
위의 코드 샘플에서 프록시 1을 프록시 2로 호출하면 런타임 시 기존 경로(라우터 > MP)를 통해 요청을 라우팅해야 한다는 의미입니다. 클라이언트에서 API를 호출하여 지연 시간에 추가되는 네트워크 홉을 여러 개 만들게 되는 것과 유사합니다. 이러한 홉은 프록시 1 요청이 이미 MP에 도달했을 것이기 때문에 필요하지 않습니다.
영향
API 프록시에서 다른 API 프록시를 호출하면 불필요한 네트워크 홉이 발생합니다. 이는 메시지 프로세서에서 다른 메시지 프로세서로 요청을 전달해야 하기 때문입니다.
권장사항
API 프록시에서 다른API 프록시를 호출할 때 프록시 연결 기능을 사용합니다. 프록시 연결은 로컬 연결을 사용하여 대상 엔드포인트(다른 API 프록시)를 참조하므로 더 효율적입니다.
코드 샘플은 엔드포인트 정의에 LocalTargetConnection을 사용한 프록시 연결을 보여줍니다.
[[["이해하기 쉬움","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 allows invoking one API proxy from another, which is useful for reusing code, but it should be done efficiently.\u003c/p\u003e\n"],["\u003cp\u003eUsing \u003ccode\u003eHTTPTargetConnection\u003c/code\u003e or custom JavaScript to invoke one API proxy from another causes extra network hops, increasing latency.\u003c/p\u003e\n"],["\u003cp\u003eInvoking one API proxy from another creates unnecessary network hops because requests are routed through the Router and Message Processor again.\u003c/p\u003e\n"],["\u003cp\u003eProxy chaining using \u003ccode\u003eLocalTargetConnection\u003c/code\u003e is the best practice for invoking API proxies, as it executes within the same Message Processor and avoids network hops.\u003c/p\u003e\n"]]],[],null,["# Antipattern: Invoking a proxy within a proxy using custom code or as a target\n\n*You're viewing **Apigee** and **Apigee hybrid** documentation.\nView [Apigee Edge](https://docs.apigee.com/api-platform/antipatterns/proxy-within-proxy) documentation.*\n\nApigee lets you invoke one API proxy from another API proxy. This feature is useful especially if\nyou have an API proxy that contains reusable code that can be used by other API proxies.\n\nAntipattern\n-----------\n\nInvoking one API proxy from another either using `HTTPTargetConnection` in the target endpoint or\ncustom JavaScript code results in additional network hop.\n\n### Invoke proxy 2 from proxy 1 using `HTTPTargetConnection`\n\nThe following code sample invokes proxy 2 from proxy 1 using `HTTPTargetConnection`: \n\n```world-of-warcraft-toc\n\u003c!-- /antipatterns/examples/2-1.xml --\u003e\n\u003cHTTPTargetConnection\u003e\n \u003cURL\u003ehttps://api-test.example.com/proxy2\u003c/URL\u003e\n\u003c/HTTPTargetConnection\u003e\n```\n\n### Invoke proxy 2 from proxy 1 from the JavaScript code\n\nThe next code sample invokes proxy 2 from proxy 1 using JavaScript: \n\n```gdscript\n\u003c!-- /antipatterns/examples/2-2.xml --\u003e\nvar response = httpClient.send('https://api-test.example.com/proxy2);\nresponse.waitForComplete();\n```\n\n### Code Flow\n\nTo understand why this has an inherent disadvantage, we need to understand the route a request\ntakes as illustrated by the diagram below:\n**Figure 1**: Code flow\n\nAs depicted in the diagram, a request traverses multiple distributed components, including the\nRouter and the Message Processor.\n\nIn the code samples above, invoking proxy 2 from proxy 1 means that the request has to be routed\nthrough the traditional route (Router \\\u003e MP) at runtime. This would be akin to invoking an API\nfrom a client thereby making multiple network hops that add to the latency. These hops are\nunnecessary considering that proxy 1 request has already *reached* the MP.\n\nImpact\n------\n\nInvoking one API proxy from another API proxy incurs unnecessary network hops, that is the\nrequest has to be passed on from one Message Processor to another Message Processor.\n\nBest practice\n-------------\n\n- Use the [proxy chaining](/apigee/docs/api-platform/fundamentals/connecting-proxies-other-proxies) feature for invoking one API Proxy from another. Proxy chaining is more efficient as it uses local connection to reference the target endpoint (another API Proxy).\n\n The code sample shows proxy chaining using `LocalTargetConnection` in your endpoint\n definition: \n\n ```world-of-warcraft-toc\n \u003c!-- /antipatterns/examples/2-3.xml --\u003e\n \u003cLocalTargetConnection\u003e\n \u003cAPIProxy\u003eproxy2\u003c/APIProxy\u003e\n \u003cProxyEndpoint\u003edefault\u003c/ProxyEndpoint\u003e\n \u003c/LocalTargetConnection\u003e\n ```\n\n The invoked API Proxy gets executed within the same Message Processor; as a result, it avoids\n the network hop as shown in the following figure:\n **Figure 2**: Code flow with proxy chaining\n\nFurther reading\n---------------\n\n- [Proxy chaining](/apigee/docs/api-platform/fundamentals/connecting-proxies-other-proxies)"]]
