Utiliser la composition de règles

<AssignMessage name="GenerateGeocodingRequest">
  <AssignTo createNew="true" type="request">GeocodingRequest</AssignTo>
  <Set>
    <QueryParams>
      <QueryParam name="address">{request.queryparam.postalcode}</QueryParam>
      <QueryParam name="region">{request.queryparam.country}</QueryParam>
      <QueryParam name="sensor">false</QueryParam>
    </QueryParams>
    <Verb>GET</Verb>
  </Set>
  <!-- Set variables for use in the final response -->
  <AssignVariable>
    <Name>PostalCode</Name>
    <Ref>request.queryparam.postalcode</Ref>
  </AssignVariable>
  <AssignVariable>
    <Name>Country</Name>
    <Ref>request.queryparam.country</Ref>
  </AssignVariable>
</AssignMessage>

Voici une brève description des éléments de ces règles. Vous pouvez en savoir plus à ce sujet dans la section Attribuer des rôles Règle relative aux messages

• <AssignMessage name> : donne un nom à cette règle. Son nom est utilisée lorsque la stratégie est référencée dans un flux.
• &lt;AssignTo&gt; : crée une variable nommée appelée GeocodingRequest. Cette variable encapsule l'objet de la requête qui sera envoyé au backend par ServiceAccroches.
• &lt;QueryParams&gt; : définit les paramètres de requête requis par la d'un appel d'API backend. Dans ce cas, l'API Geocoding a besoin de connaître le lieu, c'est-à-dire exprimé à l'aide d'un code postal et d'un identifiant de pays. L'utilisateur de l'application fournit ces informations. il suffit de l'extraire ici. Le paramètre sensor est requis par l'API. Il est "true" ou "false", et nous l'avons codée en dur en "false" ici.
• &lt;Verb&gt; : dans ce cas, nous envoyons une simple demande GET au API.
• &lt;AssignVariable&gt; : ces variables stockent les valeurs que nous que vous transmettez à l'API. Dans cet exemple, les variables seront consultées plus tard dans la réponse sont renvoyées au client.

Envoyer la requête avec ServiceCall

L'étape suivante de la séquence de composition de la règle consiste à créer une règle ServiceCallout. La La stratégie ServiceAccroche, répertoriée ci-dessous, envoie l'objet de requête que nous avons créé dans la l'ancienne règle TransferMessage au service Google Geocoding, puis enregistre le résultat dans une appelée GeocodingResponse.

<ServiceCallout name="ExecuteGeocodingRequest">
  <Request variable="GeocodingRequest"/>
  <Response>GeocodingResponse</Response>
  <HTTPTargetConnection>
    <URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
  </HTTPTargetConnection>
</ServiceCallout>

Voici une brève description des différents éléments de ces règles.

• &lt;ServiceCallout&gt; : comme pour la règle précédente, celle-ci comporte un son nom.
• <Variable de requête> : il s'agit de la variable qui a été créée dans la règle AssignMessage. Il encapsule la requête envoyée à l'API backend.
• &lt;Response&gt; : cet élément nomme une variable dans laquelle la réponse sont stockées. Comme vous le verrez, cette variable sera consultée ultérieurement par la fonction ExtractVariables .
• &lt;HTTPTargetConnection&gt; : spécifie l'URL cible du backend. API. Dans ce cas, nous indiquons que l'API doit renvoyer une réponse JSON.

Nous avons maintenant deux stratégies, l'une spécifiant les informations de requête nécessaires pour utiliser (l'API Geocoding de Google) et la seconde qui envoie réellement la requête à l'API backend. Ensuite, nous allons gérer la réponse.

<ExtractVariables name="ParseGeocodingResponse">
  <Source>GeocodingResponse</Source>
  <VariablePrefix>geocoderesponse</VariablePrefix>
  <JSONPayload>
    <Variable name="latitude">
       <JSONPath>$.results[0].geometry.location.lat</JSONPath>
    </Variable>
    <Variable name="longitude">
       <JSONPath>$.results[0].geometry.location.lng</JSONPath>
    </Variable>
  </JSONPayload>
</ExtractVariables>

Les principaux éléments de la règle ExtractVariable sont les suivants:

• <ExtractVariables name> : à nouveau, le nom de la règle est utilisé pour se référer à la règle lorsqu'elle est utilisée dans un flux.
• &lt;Source&gt; : spécifie la variable de réponse que nous avons créée dans la règle ServiceAccroche. Il s'agit de la variable à partir de laquelle la stratégie extrait les données.
• &lt;VariablePrefix&gt; : spécifie un espace de noms pour d'autres variables créées dans cette règle. Le préfixe peut être n'importe quel nom, à l'exception du préfixe réservé définis par le rôle Edge variables prédéfinies.
• &lt;JSONPayload&gt; : cet élément récupère les données de réponse qui sont qui nous intéressent et les place dans des variables nommées. En réalité, l'API Geocoding renvoie plus d'informations que la latitude et la longitude. Cependant, ce sont les seules valeurs dont nous avons besoin pour cet exemple. Vous pouvez voir le rendu complet du fichier JSON renvoyé par l'API Geocoding. dans les API documentation. Les valeurs de geometry.location.lat et geometry.location.lng sont simplement deux des nombreux champs de l'objet JSON renvoyé.

Ce n'est peut-être pas évident, mais il est important de voir que ExtractVariables produit deux variables dont les noms sont composés du préfixe de variable (geocoderesponse) et des valeurs réelles de variables qui sont spécifiés dans la stratégie. Ces variables sont stockées proxy d'API et sera disponible pour d'autres règles dans le flux de proxy, car vous voir. Les variables sont les suivantes:

• geocoderesponse.latitude
• geocoderesponse.longitude

La majeure partie du travail est maintenant terminée. Nous avons créé un ensemble de trois stratégies requête, appeler une API backend et analyser les données JSON renvoyées. Dans les dernières étapes, nous transmettrons les données de cette partie du flux vers une autre règle AffectMessage, appelez le deuxième backend (API Google Elevation), puis renvoyez nos données combinées au développeur de l'application.

<AssignMessage name="AssignElevationParameters">
<Remove>
    <QueryParams>
      <QueryParam name="country"/>
      <QueryParam name="postalcode"/>
    </QueryParams>
  </Remove>
  <Set>
    <QueryParams>
      <QueryParam name="locations">{geocoderesponse.latitude},{geocoderesponse.longitude}</QueryParam>
      <QueryParam name="sensor">false</QueryParam>
    </QueryParams>
  </Set>
</AssignMessage>

Si vous examinez l'API Google Elevation, vous constaterez qu'elle nécessite deux paramètres de requête. La première s'appelle locations, et sa valeur est la latitude et la longitude (valeurs séparées par une virgule). L'autre paramètre est sensor, qui est obligatoire et doit "true" ou "false". La chose la plus importante à noter à ce stade est que la requête que nous créons ici ne nécessite pas d'objet ServiceAccroche. Nous n'avons pas besoin d'appeler la seconde l'API à partir d'un objet ServiceCallout, car nous pouvons appeler l'API backend à partir de l'objet Point de terminaison cible. Si vous y réfléchissez, nous disposons de toutes les données dont nous avons besoin pour appeler le service Google Elevation API Le message de requête généré à cette étape ne nécessite pas d'appel de service, car la méthode générée pour le pipeline de requête principal, et sera donc simplement transférée par ProxyEndpoint vers TargetEndpoint, en suivant la règle de routage configurée pour ce proxy d'API TargetEndpoint gère la connexion avec l'API distante. Notez que l'URL de la page L'API d'élévation est définie dans le protocole HTTPConnection pour le point de terminaison TargetEndpoint. API Elevation documentation si vous souhaitez en savoir plus. Les paramètres de requête que nous avons stockés précédemment, country et postalcode ne sont plus nécessaires, nous les supprimons donc ici.

Brève pause: retour au flux

À ce stade, vous vous demandez peut-être pourquoi nous ne créons pas d'autre règle ServiceAccroche. Après nous avons créé un autre message. Comment ce message est-il envoyé à la cible, API Elevation ? La réponse se trouve dans la règle <RouteRule> du flux. &lt;RouteRule&gt; spécifie ce qu'il faut faire des messages de demande restants après la balise <Request> de le flux a été exécuté. TargetEndpoint spécifié par cette règle <RouteRule> indique au Proxy d'API pour distribuer le message à http://maps.googleapis.com/maps/api/elevation/xml.

Si vous avez téléchargé l'exemple de proxy d'API, vous trouverez le XML TargetProxy dans le fichier doc-samples/policy-mashup-cookbook/apiproxy/targets/default.xml

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <!-- This is where we define the target. For this sample we just use a simple URL. -->
    <URL>http://maps.googleapis.com/maps/api/elevation/xml</URL>
  </HTTPTargetConnection>
</TargetEndpoint>

Il ne nous reste plus qu'à traiter la réponse de l'API Google Elevation, terminé.

$ curl "http://{myorg}-test.apigee.net/policy-mashup-cookbook?country=us&postalcode=08008"

La réponse inclut l'emplacement géocodé du centre du code postal fourni par l'utilisateur final de l'application, combinées à l'altitude à cet emplacement géocodé. Les données ont été récupérées à partir de deux API backend, combinées aux stratégies associées au proxy d'API, et renvoyés au client dans une seule réponse.

{  
   "country":"us",
   "postalcode":"08008",
   "elevation":{  
      "meters":0.5045232,
      "feet":1.6552599030345978
   },
   "location":{  
      "latitude":39.75007129999999,
      "longitude":-74.1357407
   }
}

Résumé

Cette rubrique du livre de recettes vous a expliqué comment utiliser le modèle de composition de règles pour créer un application composite. de données provenant de plusieurs sources backend. La composition des règles est un modèle couramment utilisé dans les API le développement de proxy pour ajouter des fonctionnalités de création à votre API.