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. Obtén más información al respecto en la sección Asignar Política de mensajes.

• <AssignMessage name>: Asigna un nombre a esta política. El nombre es se usa cuando se hace referencia a la política en un flujo.
• &lt;AssignTo&gt;: Crea una variable con nombre llamada GeocodingRequest. Esta variable encapsula el objeto de la solicitud que enviará el backend al backend Política ServicePrompt.
• &lt;QueryParams&gt;: 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 es expresada con un código postal y un ID de país. El usuario de la aplicación proporciona esta información. solo lo extraemos aquí. El parámetro sensor es obligatorio para la API y se verdadero o falso, y lo codificamos como falso aquí.
• &lt;Verb&gt;. En este caso, se realiza una solicitud GET simple al en la API de Cloud.
• &lt;AssignVariable&gt;: estas variables almacenan los valores que se reciben. pasando a la API. En este ejemplo, se accederá a las variables más adelante en la respuesta. mostrar al cliente.

Envía la solicitud con ServiceCallout

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

• &lt;ServiceCallout&gt;: al igual que con la política anterior, esta incluye de la fuente de datos.
• <Variable de solicitud>: es la variable que se creó en con la políticaAssignMessage. Encapsula la solicitud que se dirige a la API de backend.
• &lt;Response&gt;: este elemento nombra una variable en la que la respuesta cuando se almacena. Como verás, el ExtractVariables accederá a esta variable más adelante política de la empresa.
• &lt;HTTPTargetConnection&gt;: especifica la URL de destino del backend. en la API de Cloud. 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 de backend (API de Geocoding de Google), y la segunda que envía la solicitud a la API de backend. A continuación, manejaremos 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 consulta la política cuando se usan en un flujo.
• &lt;Source&gt;: especifica la variable de respuesta que creamos en la política ServicePrompt. Esta es la variable de la que esta política extrae datos.
• &lt;VariablePrefix&gt;: El prefijo de variable especifica un espacio de nombres para otras variables creadas en esta política. El prefijo puede ser cualquier nombre, excepto el nombre reservado definidos por la ruta de aprendizaje variables predefinidas.
• &lt;JSONPayload&gt;: este elemento recupera los datos de respuesta que se que nos interesan y lo coloca en variables con nombre. De hecho, la API de Geocoding proporciona 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 las APIs documentación. Los valores de geo.location.lat y geometría.location.lng simplemente son dos de los numerosos campos en el objeto JSON que se devuelve.

Puede no ser obvio, pero es importante ver que ExtractVariables produce dos variables cuyos nombres constan del prefijo de la variable (georesponse) y el código de variables que se especifican en la política. Estas variables se almacenan proxy de API y estará disponible para otras políticas dentro del flujo del proxy, ver. Las variables son las siguientes:

• geocoderesponse.latitude
• geocoderesponse.longitude

Ahora, la mayor parte del trabajo está terminado. Creamos un compuesto de tres políticas que forman llamar a una API de backend y analizar los datos JSON que se muestran. En los últimos pasos, le enviaremos datos de esta parte del flujo en otra política deAssignMessage, llama al segundo backend (API de Google Elevation), y devolver nuestros datos combinados 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 puede ser verdadero o falso. Lo más importante que se debe tener en cuenta en este punto es que la solicitud del mensaje que creamos aquí no requiere un ServiceTexto destacado. No necesitamos llamar a la segunda API de un ServicePrompt de servicio en este punto porque podemos llamar a la API de backend desde la API de TargetEndpoint. Si lo piensas, tenemos todos los datos que necesitamos para llamarlos Elevaciones de Google API El mensaje de solicitud generado en este paso no requiere un ServicePrompt, ya que el para la canalización de la solicitud principal. Por lo tanto, la reenvía 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 Elevation se define en HTTPConnection para el TargetEndpoint. API de Elevation documentación, 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í.

Pausa breve: Volver al flujo

En este punto, es posible que te preguntes por qué no estamos creando otra política ServiceCallout. Después del creamos otro mensaje. ¿Cómo se envía ese mensaje al destino, al servicio ¿API de Elevation? La respuesta está en <RouteRule> del flujo. &lt;RouteRule&gt; especifica qué hacer con los mensajes de solicitud restantes después de <Request> parte de se ejecutó el flujo. El TargetEndpoint especificado por esta <RouteRule> le dice al proxy de API para entregar el mensaje a http://maps.googleapis.com/maps/api/elevation/xml.

Si descargaste el proxy de API de muestra, podrás 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 debemos procesar la respuesta de la Google Elevation API. 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 aplicación, en combinación con la elevación de esa ubicación geocodificada. Los datos fueron recuperado de dos APIs de backend, combinado con políticas adjuntas al proxy de API mostrar 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 explica cómo usar el patrón de composición de políticas para crear una mashup de datos de múltiples fuentes de backend. La composición de políticas es un patrón común que se usa en la API y el desarrollo de proxy para agregar funciones de creatividad a la API.