Antipattern: definire più ProxyEndpoint in un proxy API
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Stai visualizzando la documentazione di Apigee e Apigee hybrid.
Visualizza la documentazione di
Apigee Edge.
La configurazione di ProxyEndpoint definisce il modo in cui le app client utilizzano le API tramite Apigee.
ProxyEndpoint definisce l'URL del proxy API e il comportamento di un proxy: quali criteri applicare
e a quali endpoint di destinazione inoltrare, nonché le condizioni che devono essere soddisfatte per l'esecuzione di questi criteri o
regole di inoltro.
In breve, la configurazione di ProxyEndpoint definisce tutto ciò che deve essere fatto per implementare un'API.
Antipattern
Un proxy API può avere uno o più endpoint proxy. La definizione di più ProxyEndpoint è un meccanismo semplice per implementare più API in un unico proxy. In questo modo, puoi riutilizzare i criteri
e/o la logica di business prima e dopo l'invocazione di un endpoint di destinazione.
D'altra parte, quando definisci più ProxyEndpoint in un singolo proxy API, finisci per combinare concettualmente molte API non correlate in un unico artefatto. Ciò rende i proxy API più difficili da leggere, comprendere, eseguire il debug e gestire. Questo mina la filosofia principale dei proxy API: semplificare per gli sviluppatori la creazione e la gestione delle API.
Impatto
Più ProxyEndpoint in un proxy API possono:
Rendere difficile per gli sviluppatori comprendere e gestire il proxy API.
Offuscare i dati e le analisi. Per impostazione predefinita, i dati di analisi vengono aggregati a livello di proxy. Non è prevista una suddivisione delle metriche per endpoint proxy, a meno che non crei report personalizzati.
Rendere difficile la risoluzione dei problemi relativi ai proxy API.
Best practice
Quando implementi un nuovo proxy API o ne ridisegni uno esistente, segui le seguenti best practice:
Implementa un proxy API con un singolo ProxyEndpoint.
Se sono presenti più API che condividono un server di destinazione comune e/o richiedono la stessa logica prima o dopo l'invocazione del server di destinazione, valuta la possibilità di utilizzare flussi condivisi per implementare questa logica in proxy API diversi.
Se sono presenti più API che condividono un percorso base iniziale comune, ma differiscono nel suffisso,
utilizza flussi condizionali in un singolo ProxyEndpoint.
Se esiste un proxy API con più ProxyEndpoint e non ci sono problemi,
non è necessario intervenire.
L'utilizzo di un ProxyEndpoint per proxy API comporta:
Proxy più semplici e facili da gestire
In Analytics verranno riportate informazioni più dettagliate, come il rendimento del proxy e il tempo di risposta del target, anziché raggruppate per tutti i ProxyEndpoints
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-08-21 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)"]]
