Antipatrón: Define varios ProxyEndpoints en un proxy de API
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Estás viendo la documentación de Apigee y Apigee Hybrid.
Consulta la documentación de Apigee Edge.
La configuración de ProxyEndpoint define la manera en que las aplicaciones de cliente consumen las API a través de Apigee.
ProxyEndpoint define la URL del proxy de API y el comportamiento de un proxy: a qué políticas aplicar y a qué extremos de destino se debe enrutar, y las condiciones que se deben cumplir para que se ejecuten estas políticas o reglas de enrutamiento que se deben ejecutar.
En resumen, la configuración de ProxyEndpoint define todo lo que se debe hacer para implementar una API.
Antipatrón
Un proxy de API puede tener uno o más extremos del proxy. Definir varios ProxyEndpoints es un mecanismo fácil y simple para implementar varias API en un solo proxy. Esto te permite reutilizar políticas o lógica empresarial antes y después de la invocación de un TargetEndpoint.
Por otro lado, cuando defines varios ProxyEndpoints en un solo proxy de API, comienzas a combinar de manera conceptual varias API no relacionadas en un solo artefacto. Hace que los proxies de API sean más difíciles de leer, comprender, depurar y mantener. Esto elimina la filosofía principal de los proxies de API, lo que facilita la creación y el mantenimiento de las API para los desarrolladores.
Impacto
Varios ProxyEndpoints en un proxy de API pueden hacer lo siguiente:
Dificultar que los desarrolladores comprendan y mantengan el proxy de la API.
Ofuscar estadísticas. De forma predeterminada, los datos de estadísticas se agregan a nivel del proxy. No existe un desglose de métricas por extremo de proxy, a menos que crees informes personalizados.
Dificultar la solución de problemas con los proxies de API.
Práctica recomendada
Cuando implementes un proxy de API nuevo o rediseñes un proxy de API existente, usa las siguientes recomendaciones:
Implementa un proxy de API con un solo ProxyEndpoint.
Si hay varias API que comparten un servidor de destino común o requieren la misma lógica previa o posterior a la invocación del servidor de destino, considera usar flujos compartidos para implementar esa lógica en diferentes proxies de API.
Si hay varias API que comparten una ruta base de inicio común, pero tienen diferentes sufijos, usa flujos condicionales en un solo ProxyEndpoint.
Si existe un proxy de API con varios ProxyEndpoints, y si no hay problemas con él, no es necesario que realices ninguna acción.
El uso de un ProxyEndpoint por proxy de API da como resultado lo siguiente:
Es más simple y fácil mantener los proxies.
Se proporcionará información más precisa en Analytics, como el rendimiento del proxy y el tiempo de respuesta objetivo, en lugar de implementarse para todos los ProxyEndpoints.
Solución de problemas más rápida y resolución de errores.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)"]]
