Usa la composición de políticas

<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>

A continuación, se muestra una breve descripción de los elementos de esta política. Puedes obtener más información sobre esta política en Política AssignMessage.

• <AssignMessage name>: Le da un nombre a esta política. El nombre se usa cuando se hace referencia a la política en un flujo.
• <AssignTo> : Crea una variable con nombre llamada GeocodingRequest. Esta variable encapsula el objeto de solicitud que la política ServiceCallout enviará al backend.
• <QueryParams> : Establece los parámetros de consulta que necesita la llamada a la API de backend. En este caso, la API de Geocoding necesita conocer la ubicación, que se expresa con un código postal y un ID de país. El usuario de la app proporciona esta información, y nosotros simplemente la extraemos aquí. La API requiere el parámetro sensor, que es verdadero o falso, y aquí lo codificamos como falso.
• <Verbo> : En este caso, realizamos una solicitud GET simple a la API.
• <AssignVariable> : Estas variables almacenan los valores que estamos pasando a la API. En este ejemplo, se accederá a las variables más adelante en la respuesta que se muestra al cliente.

Envía la solicitud con ServiceCallout

El siguiente paso en la secuencia de composición de políticas es crear una política ServiceCallout. La política ServiceCallout, que se muestra a continuación, envía el objeto de solicitud que creamos en la política AssignMessage anterior al servicio de Geocoding de Google y guarda el resultado en una variable llamada GeocodingResponse.

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

A continuación, se muestra una breve descripción de los elementos de esta política.

• <ServiceCallout> : Al igual que la política anterior, esta tiene un nombre.
• <Request variable> : Esta es la variable que se creó en la política AssignMessage. Encapsula la solicitud que va a la API de backend.
• <Response> : Este elemento nombra una variable en la que se almacena la respuesta. Como verás, la política ExtractVariables accederá a esta variable más adelante.
• <HTTPTargetConnection> : Especifica la URL de destino de la API de backend API. En este caso, especificamos que la API muestre una respuesta JSON.

Ahora tenemos dos políticas: una que especifica la información de solicitud necesaria para usar la API de backend (la API de Geocoding de Google) y la segunda que envía la solicitud a la API de backend. A continuación, controlaremos la respuesta.

<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>

Los elementos clave de la política ExtractVariable son los siguientes:

• <ExtractVariables name> : Una vez más, el nombre de la política se usa para hacer referencia a la política cuando se usa en un flujo.
• <Source> : Especifica la variable de respuesta que creamos en la política ServiceCallout. Esta es la variable de la que esta política extrae datos.
• <VariablePrefix> : El prefijo de variable especifica un espacio de nombres para otras variables creadas en esta política. El prefijo puede ser cualquier nombre, excepto los nombres reservados definidos por las variables predefinidas de Edge.
• <JSONPayload> : Este elemento recupera los datos de respuesta que nos interesan y los coloca en variables con nombre. De hecho, la API de Geocoding muestra mucha más información que la latitud y la longitud. Sin embargo, estos son los únicos valores que necesitamos para esta muestra. Puedes ver una representación completa del JSON que muestra la API de Geocoding en la documentación de la API. Los valores de geometry.location.lat y geometry.location.lng son simplemente dos de los muchos campos del objeto JSON que se muestra.

Es posible que no sea obvio, pero es importante ver que ExtractVariables produce dos variables cuyos nombres constan del prefijo de variable (geocoderesponse) y los nombres de variable reales que se especifican en la política. Estas variables se almacenan en el proxy de API y estarán disponibles para otras políticas dentro del flujo del proxy, como verás. Las variables son las siguientes:

• geocoderesponse.latitude
• geocoderesponse.longitude

La mayor parte del trabajo ya está hecha. Creamos una composición de tres políticas que forman una solicitud, llaman a una API de backend y analizan los datos JSON que se muestran. En los pasos finales, ingresaremos datos de esta parte del flujo en otra política AssignMessage, llamaremos a la segunda API de backend (API de Elevation de Google) y mostraremos nuestros datos combinados al desarrollador de apps.

<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 examinas la API de Elevation de Google, verás que toma dos parámetros de consulta. El primero se llama locations y su valor es la latitud y la longitud (valores separados por comas). El otro parámetro es sensor, que es obligatorio y debe ser verdadero o falso. Lo más importante que debes tener en cuenta en este punto es que el mensaje de solicitud que creamos aquí no requiere un ServiceCallout. No necesitamos llamar a la segunda API desde un ServiceCallout en este punto porque podemos llamar a la API de backend desde el TargetEndpoint del proxy. Si lo piensas, tenemos todos los datos que necesitamos para llamar a la API de Elevation de Google El mensaje de solicitud generado en este paso no requiere un ServiceCallout, ya que la solicitud generada para la canalización de solicitud principal, por lo que el ProxyEndpoint simplemente la reenviará al TargetEndpoint, siguiendo la RouteRule configurada para este proxy de API. El TargetEndpoint administra la conexión con la API remota. (Recuerda que la URL de la API de Elevation se define en HTTPConnection para el TargetEndpoint. Documentación de la API de Elevation si deseas obtener más información. Los QueryParams que almacenamos anteriormente, country y postalcode, ya no son necesarios, por lo que los quitamos aquí.

Breve pausa: Volver al flujo

En este punto, es posible que te preguntes por qué no creamos otra política ServiceCallout. Después de todo, creamos otro mensaje. ¿Cómo se envía ese mensaje al destino, la API de Elevation de Google ? La respuesta está en el elemento <RouteRule> del flujo. <RouteRule> especifica qué hacer con los mensajes de solicitud restantes después de que se ejecuta la parte <Request> de el flujo. El TargetEndpoint especificado por este <RouteRule> le indica al proxy de API que entregue el mensaje a http://maps.googleapis.com/maps/api/elevation/xml.

Si descargaste el proxy de API de muestra, puedes encontrar el XML de TargetProxy en el archivo 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>

Ahora, solo necesitamos procesar la respuesta de la API de Elevation de Google y listo.

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

La respuesta incluye la ubicación geocodificada para el centro del código postal proporcionado por el usuario final de la app, combinada con la elevación en esa ubicación geocodificada. Los datos se recuperaron de dos APIs de backend, se combinaron con políticas adjuntas al proxy de API y se mostraron al cliente en una sola respuesta.

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

Resumen

En este tema de la guía de soluciones, se explicó cómo usar el patrón de composición de políticas para crear un mashup de datos de varias fuentes de backend. La composición de políticas es un patrón común que se usa en el desarrollo de proxies de API para agregar funciones creativas a tu API.