Antipadrão: defina vários ProxyEndpoints em um proxy de API
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Esta é a documentação da Apigee e da Apigee híbrida.
Confira a documentação da Apigee Edge.
A configuração ProxyEndpoint define a maneira como os aplicativos clientes consomem as APIs por meio da Apigee.
O ProxyEndpoint define o URL do proxy da API e como um proxy se comporta: quais políticas serão aplicadas
e em quais endpoints de destino serão roteados, e as condições que precisam ser atendidas para que essas políticas ou
regras de rota sejam executadas.
Em resumo, a configuração de ProxyEndpoint define tudo o que precisa ser feito para implementar uma
API.
Antipadrão
Um proxy de API pode ter um ou mais endpoints de proxy. Definir vários ProxyEndpoints é um mecanismo
simples e fácil para implementar várias APIs em apenas um proxy. Isso permite que você reutilize as políticas
e/ou a lógica de negócios antes e depois da invocação de um TargetEndpoint.
Por outro lado, ao definir vários ProxyEndpoints em apenas um proxy de API, você acabará
combinando diversas APIs não relacionadas em um único artefato. Isso dificulta a leitura, a compreensão,
a depuração e a manutenção dos proxies da API. Ou seja, a principal filosofia dos proxies da API vai por água abaixo: facilitar
a criação e a manutenção de APIs para os desenvolvedores.
Impacto
Vários ProxyEndpoints em um proxy de API podem trazer os seguintes problemas:
Dificultar a compreensão e a manutenção dos desenvolvedores no proxy da API.
Ofuscar a análise. Por padrão, os dados de análise são agregados no nível do proxy. Não há
detalhamento de métricas por endpoint de proxy, a menos que você crie relatórios personalizados.
Dificultar a solução de problemas com proxies de API.
Prática recomendada
Ao implementar um novo proxy de API ou reprojetar um proxy de API existente, use as
seguintes práticas recomendadas:
Implemente um proxy de API com apenas um ProxyEndpoint.
Se houver várias APIs que compartilham o servidor de destino comum e/ou exigir a mesma lógica antes
ou depois da invocação do servidor de destino, use os fluxos compartilhados para implementar essa lógica em
diferentes proxies da API.
Se houver várias APIs que compartilham um caminho base comum, mas são diferentes no sufixo,
use fluxos condicionais em apenas um ProxyEndpoint.
Se houver um proxy de API com vários ProxyEndpoints e se não houver problemas com ele,
nenhuma ação será necessária.
Usar um ProxyEndpoint por proxy da API melhora os pontos a seguir:
Torna os proxies mais simples e fáceis de manter.
Algumas informações melhores no Analytics, como desempenho do proxy e tempo de resposta de destino, serão
registradas separadamente, em vez de serem agrupadas para todos os ProxyEndpoints.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)"]]
