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 incluye una breve descripción de los elementos de esta política. Puedes obtener más información sobre esta política en la política de Asignar mensajes.

• <AssignMessage name>: Asigna 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 enviará la política ServiceHighlight 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 del país. El usuario de la app proporciona esta información, que simplemente debemos extraer aquí. La API requiere el parámetro sensor, que es verdadero o falso. Aquí solo se codifica como falso.
• <Verb>: en este caso, realizaremos una solicitud GET simple a la API.
• <AssignVariable>: Estas variables almacenan los valores que pasamos a la API. En este ejemplo, se accederá a las variables más adelante en la respuesta que se muestre al cliente.

Envía la solicitud con ServicePrompt

El siguiente paso en la secuencia de composición de la política es crear una política ServiceCallout. La política ServiceReferencia, que se indica a continuación, envía el objeto de solicitud que creamos en la política AssignMessage anterior al servicio Google Geocoding 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 incluye una breve descripción de los elementos de esta política.

• <ServiceCallout>: Al igual que con la política anterior, esta tiene nombre.
• <Variable de solicitud>: Esta es la variable que se creó en la políticaAssignMessage. Encapsula la solicitud que se dirige 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. 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 (API de Geocoding de Google) y la segunda que realmente 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>: Nuevamente, 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 ServiceHighlight. Esta es la variable de la que esta política extrae los datos.
• <VariablePrefix>: El prefijo de la variable especifica un espacio de nombres para otras variables creadas en esta política. El prefijo puede ser cualquier nombre, excepto los nombres reservados que definen 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 renderización completa del JSON que muestra la API de Geocoding en la documentación de la API. Los valores de geomet.location.lat y energy.location.lng son simplemente dos de los numerosos campos en el objeto JSON que se muestra.

Puede que no sea evidente, pero es importante ver que ExtractVariables produce dos variables cuyos nombres constan del prefijo de la variable (georesponse) y los nombres reales de las variables 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:

• geocoderesponse.latitude
• geocoderesponse.longitude

Ya terminamos la mayor parte del trabajo. Creamos un compuesto de tres políticas que forman una solicitud, llaman a una API de backend y analizan los datos JSON que se muestran. En los últimos pasos, incorporaremos los datos de esta parte del flujo a otra política deAssignMessage, llamaremos a la segunda API de backend (API de Google Elevation), y mostraremos la combinación de datos al desarrollador de la app.

<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 Google Elevation API, 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 ServiceReferencia. En este momento, no es necesario llamar a la segunda API desde un ServiceReferencia, ya que se puede 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 Elevations de Google. El mensaje de solicitud generado en este paso no requiere un ServiceReferencia, ya que la solicitud generada para la canalización de la solicitud principal la reenviará el ProxyEndpoint al TargetEndpoint, siguiendo la RouteRule configurada para este proxy de API. 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 antes, country y postalcode, ya no son necesarios, por lo que los quitamos aquí.

Pausa breve: Vuelve al flujo

En este punto, es posible que se pregunte por qué no creamos otra política de ServiceReferencia. Después de todo, creamos otro mensaje. ¿Cómo se envía ese mensaje al destino, la API de Google Elevation? La respuesta está en el elemento <RouteRule> del flujo. <RouteRule> especifica qué hacer con los mensajes de solicitud restantes después de que se haya ejecutado la parte <Request> del flujo. El TargetEndpoint especificado por esta <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"

En la respuesta, se incluye la ubicación geocodificada del centro del código postal que proporciona el usuario final de la app, combinada con la elevación de esa ubicación geocodificada. Los datos se recuperaron de dos API 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 una 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 del proxy de API para agregar funciones de creatividades a la API.