Vous consultez la documentation d'Apigee Edge.
Consultez la
documentation Apigee X. en savoir plus
Un proxy d'API est une façade gérée pour des services de backend. Une configuration de proxy d'API de base se compose d'un ProxyEndpoint (qui définit l'URL du proxy d'API) et d'un TargetEndpoint (qui définit l'URL du service de backend).
Apigee Edge offre une grande flexibilité pour créer des comportements sophistiqués en plus de ce modèle. Par exemple, vous pouvez ajouter des règles visant à contrôler la manière dont l'API traite une requête client avant de l'envoyer au service de backend, ou à manipuler la réponse reçue du service de backend avant de la transférer au client. Vous pouvez appeler d'autres services à l'aide de règles d'appel de service, ajouter un comportement personnalisé en ajoutant du code JavaScript, et même créer un proxy d'API qui n'appelle pas de service de backend.
Antimodèle
Il est techniquement possible d'utiliser des appels de service pour appeler un service de backend dans un proxy d'API sans routes vers un point de terminaison cible, mais cela entraîne une perte de données d'analyse sur les performances du service externe.
Un proxy d'API qui ne contient pas de routes cibles peut être utile si vous n'avez pas besoin de transférer le message de requête au point de terminaison cible. À la place, le point de terminaison proxy effectue tous les traitements nécessaires. Par exemple, le point de terminaison proxy peut récupérer les données d'une recherche dans le magasin clé/valeur du service d'API et renvoyer la réponse sans appeler de service de backend.
Vous pouvez définir une route nulle dans un proxy d'API, comme indiqué ci-dessous:
<RouteRule name="noroute"/>
Un proxy utilisant une route nulle est dit "sans cible", car il n'appelle pas de service de backend cible.
Il est techniquement possible d'ajouter un appel de service à un proxy cible pour appeler un service externe, comme illustré dans l'exemple ci-dessous:
<!-- /antipatterns/examples/service-callout-no-target-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
<Description/>
<FaultRules/>
<PreFlow name="PreFlow">
<Request>
<Step>
<Name>ServiceCallout-InvokeBackend</Name>
</Step>
</Request>
<Response/>
</PreFlow>
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
<Flows/>
<HTTPProxyConnection>
<BasePath>/no-target-proxy</BasePath>
<Properties/>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
<RouteRule name="noroute"/>
</ProxyEndpoint>
Toutefois, le proxy ne peut pas fournir d'informations d'analyse sur le comportement du service externe (comme le temps de traitement ou les taux d'erreur), ce qui complique l'évaluation des performances du service externe.
Impact
- Les informations d'analyse sur l'interaction avec le service externe (codes d'erreur, temps de réponse, performances cibles, etc.) ne sont pas disponibles.
- Toute logique spécifique requise avant ou après l'appel du service est incluse dans la logique de proxy globale, ce qui complique la compréhension et la réutilisation.
Bonne pratique
Si un proxy d'API interagit avec un service externe unique, le proxy doit suivre le modèle de conception de base, dans lequel le service de backend est défini comme point de terminaison cible du proxy d'API. Un proxy sans règle de routage vers un point de terminaison cible ne doit pas appeler de service de backend à l'aide de la règle ServiceCallout.
La configuration de proxy suivante met en œuvre le même comportement que dans l'exemple ci-dessus, mais respecte les bonnes pratiques:
<!-- /antipatterns/examples/service-callout-no-target-2.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
<Description/>
<FaultRules/>
<PreFlow name="PreFlow">
<Request/>
<Response/>
</PreFlow>
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
<Flows/>
<HTTPProxyConnection>
<BasePath>/simple-proxy-with-route-to-backend</BasePath>
<Properties/>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
<RouteRule name="default">
<TargetEndpoint>default</TargetEndpoint>
</RouteRule>
</ProxyEndpoint>
Utilisez des appels de service pour prendre en charge des scénarios composites, dans lesquels vous souhaitez appeler des services externes avant ou après l'appel au point de terminaison cible. Les appels de service n'ont pas vocation à remplacer l'appel au point de terminaison cible.