Antimodèle : utilisez la règle d'appel de service pour appeler un service de backend dans un proxy d'API sans cible.

Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Consultez la documentation d'Apigee Edge.

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 (définissant l'URL du proxy d'API) et d'un TargetEndpoint (définissant l'URL du service de backend).

Apigee offre une grande flexibilité pour créer un comportement sophistiqué par-dessus 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 des 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

L'utilisation d'appels de service pour appeler un service de backend dans un proxy d'API sans routes vers un point de terminaison cible est techniquement réalisable, mais entraîne la 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 sans 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 l'heure du traitement ou les taux d'erreur), ce qui rend l'évaluation des performances du service externe difficile.

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.

Documentation complémentaire