Anti-Pattern: Mehrere ProxyEndpoints in einem API-Proxy definieren
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid. Apigee Edge-Dokumentation aufrufen.
Die ProxyEndpoint-Konfiguration legt fest, wie Clientanwendungen die APIs über Apigee nutzen.
Der ProxyEndpoint definiert die URL des API-Proxys und wie sich ein Proxy verhält: Welche Richtlinien angewendet werden und welche Endpunkte zu der Route führen sollen, sowie die Bedingungen, die erfüllt werden müssen, damit diese Richtlinien oder Routingregeln ausgeführt werden.
Die ProxyEndpoint-Konfiguration definiert alle Aspekte, die zum Implementieren einer API erforderlich sind.
Anti-Pattern
Ein API-Proxy kann einen oder mehrere Proxy-Endpunkte haben. Das Definieren mehrerer ProxyEndpoints ist ein einfacher Mechanismus, um mehrere APIs in einem einzelnen Proxy zu implementieren. Auf diese Weise können Sie Richtlinien und/oder Geschäftslogik vor und nach dem Aufruf eines TargetEndpoint wiederverwenden.
Wenn Sie hingegen mehrere ProxyEndpoints in einem einzigen API-Proxy definieren, kombinieren Sie am Ende konzeptionell viele nicht miteinander verbundene APIs in einem einzigen Artefakt. Hierdurch sind die API-Proxys schwieriger zu lesen, zu verstehen, zu debuggen und zu verwalten. Dies konterkariert die Hauptphilosophie von API-Proxys: Entwicklern die Erstellung und Pflege von APIs zu erleichtern.
Auswirkungen
Mehrere ProxyEndpoints in einem API-Proxy können:
Es Entwicklern schwer machen, den API-Proxy zu verstehen und zu verwalten.
Analysen verschleiern. Standardmäßig werden Analysedaten auf Proxyebene zusammengefasst. Messwerte werden nicht nach Proxyendpunkten aufgeführt, es sei denn, Sie erstellen benutzerdefinierte Berichte.
Die Fehlerbehebung mit API-Proxys erschweren.
Best Practice
Wenn Sie einen neuen API-Proxy implementieren oder einen vorhandenen API-Proxy optimieren, verwenden Sie die folgenden Best Practices:
Implementieren Sie einen API-Proxy mit einem einzelnen ProxyEndpoint.
Wenn es mehrere APIs gibt, die einen gemeinsamen Zielserver nutzen und/oder dieselbe Logik vor oder nach dem Aufruf des Zielservers erfordern, sollten Sie die Verwendung freigegebener Abläufe in Betracht ziehen, um diese Logik in verschiedenen API-Proxys zu implementieren.
Wenn mehrere APIs denselben gemeinsamen Basispfad haben, aber sich im Suffix unterscheiden, verwenden Sie bedingte Abläufe in einem einzelnen ProxyEndpoint.
Wenn ein API-Proxy mit mehreren ProxyEndpoints vorhanden ist und keine Probleme auftreten, müssen Sie keine Maßnahmen ergreifen.
Die Verwendung eines ProxyEndpoint pro API-Proxy führt zu Folgendem:
Proxies, die einfacher sind und leichter zu verwalten sind
Präzisere Analytics-Informationen, wie z. B. Proxyleistung und Zielantwortzeit, werden separat gemeldet, anstatt für alle ProxyEndpoints auf einen Blick.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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,["*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\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\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\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- [API Proxy Configuration Reference](/apigee/docs/api-platform/reference/api-proxy-configuration-reference)\n- [Reusable shared flows](/apigee/docs/api-platform/fundamentals/shared-flows)"]]
