Antimodèle : définir plusieurs points de terminaison proxy dans un proxy d'API
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Vous consultez la documentation d'Apigee et d'Apigee hybrid. Consultez la documentation d'Apigee Edge.
La configuration de point de terminaison proxy définit la manière dont les applications clientes utilisent les API via Apigee.
Le point de terminaison proxy définit l'URL du proxy d'API et le comportement d'un proxy : les règles à appliquer et les points de terminaison cibles vers lesquels acheminer, et les conditions à respecter pour ces règles ou règles de routage à exécuter.
En bref, la configuration de point de terminaison proxy définit tout ce qui doit être fait pour mettre en œuvre une API.
Antimodèle
Un proxy d'API peut avoir un ou plusieurs points de terminaison proxy. La définition de plusieurs points de terminaison proxy est un mécanisme simple et facile pour mettre en œuvre plusieurs API dans un seul proxy. Cela vous permet de réutiliser des règles et/ou une logique métier avant et après l'appel d'un point de terminaison cible.
D'autre part, lorsque vous définissez plusieurs ProxyEndpoints dans un seul proxy d'API, vous finissez par combiner conceptuellement de nombreuses API sans rapport entre elles en un seul artefact. Cela rend les proxys d'API plus difficiles à lire, comprendre, déboguer et gérer, ce qui va à l'encontre de la philosophie principale des proxys d'API : faciliter la création et la gestion des API pour les développeurs.
Impact
Plusieurs points de terminaison proxy dans un proxy d'API peuvent :
Rendre la compréhension et la gestion du proxy d'API par les développeurs difficiles.
Obscurcir les données d'analyse. Par défaut, les données d'analyse sont agrégées au niveau du proxy. Il n'y a aucune répartition des métriques par point de terminaison proxy, sauf si vous créez des rapports personnalisés.
Rendre la résolution des problèmes liés aux proxys d'API difficile.
Bonne pratique
Lorsque vous mettez en œuvre un nouveau proxy d'API ou modifiez un proxy d'API existant, suivez les bonnes pratiques suivantes :
Mettez en œuvre un proxy d'API avec un seul point de terminaison proxy.
Si plusieurs API partagent le même serveur cible et/ou nécessitent la même logique pré- ou post- appel du serveur cible, envisagez d'utiliser des flux partagés pour implémenter cette logique dans différents proxys d'API.
Si plusieurs API partagent un chemin de base de départ commun, mais n'ont pas le même suffixe, utilisez des flux conditionnels dans un seul point de terminaison proxy.
S'il existe un proxy d'API avec plusieurs points de terminaison proxy et qu'il n'y a pas de problème, il n'est pas nécessaire d'effectuer d'action.
L'utilisation d'un point de terminaison proxy par proxy d'API entraîne :
Une gestion des proxys plus simple et plus facile.
Les informations améliorées dans Analytics, telles que les performances du proxy et le temps de réponse cible, sont signalées séparément au lieu d'être regroupées pour tous les points de terminaison proxy.
Un dépannage et une résolution des problèmes plus rapides.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)"]]
