Como usar a composição de política

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

Veja uma breve descrição dos elementos desta política. Saiba mais sobre o assunto política em Atribuir Política de mensagens.

• <AssignMessage name>: dá um nome à política. O nome é usada quando a política é referenciada em um fluxo.
• &lt;AssignTo&gt;: cria uma variável nomeada chamada GeocodingRequest. Essa variável encapsula o objeto de solicitação que será enviado ao back-end pelo Política de Service callout.
• &lt;QueryParams&gt;: define os parâmetros de consulta necessários para o chamada de API de back-end. Nesse caso, a API Geocoding precisa saber o local, que é expresso com um código postal e um ID de país. O usuário do aplicativo fornece essas informações, e nós os extraímos aqui. O parâmetro sensor é exigido pela API e é verdadeiro ou falso, e nós apenas fixamos no código como falso aqui.
• &lt;Verb&gt;: neste caso, estamos fazendo uma solicitação GET simples para o API.
• &lt;AssignVariable&gt;: essas variáveis armazenam os valores que estamos passando para a API. Neste exemplo, as variáveis serão acessadas mais tarde na resposta retornados ao cliente.

Envie a solicitação com ServiceCall

A próxima etapa na sequência de composição da política é criar uma política ServiceCallout. A A política ServiceCall, listada abaixo, envia o objeto de solicitação que criamos na anterior AttributionMessage ao serviço Google Geocoding, e salva o resultado em uma chamada GeocodingResponse.

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

Veja uma breve descrição dos elementos dessa política.

• &lt;ServiceCallout&gt; - Assim como na política anterior, esta tem um nome.
• <Variável da solicitação>: é a variável que foi criada no a política AttributionMessage. Ela encapsula a solicitação enviada para a API de back-end.
• &lt;Response&gt;: este elemento nomeia uma variável na qual a resposta é armazenado. Como você verá, essa variável será acessada posteriormente pelo comando política.
• &lt;HTTPTargetConnection&gt;: especifica o URL de destino do back-end. API. Nesse caso, especificamos que a API retorne uma resposta JSON.

Agora temos duas políticas, uma que especifica as informações da solicitação necessárias para usar o API de back-end (API Geocoding do Google) e a segunda que envia a solicitação para a API de back-end. A seguir, processaremos a resposta.

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

Os principais elementos da política ExtractVariable são:

• <ExtractVariables name>: o nome da política é usado para consulte a política quando ela for usada em um fluxo.
• &lt;Source&gt;: especifica a variável de resposta que criamos em a política Service callout. Esta é a variável da qual esta política extrai dados.
• &lt;VariablePrefix&gt;: o prefixo variável especifica um namespace para e outras variáveis criadas nesta política. O prefixo pode ser qualquer nome, exceto o nome definidos pela política do Edge variáveis predefinidas.
• &lt;JSONPayload&gt; - Este elemento recupera os dados de resposta que são de interesse para nós e os coloca em variáveis nomeadas. Na verdade, a API Geocoding retorna muito mais informações do que latitude e longitude. No entanto, esses são os únicos valores de que precisamos para esta amostra. É possível ver uma renderização completa do JSON retornado pela API Geocoding na API Documentação. Os valores de Geocoding.location.lat e Geolocation.location.lng são simplesmente dois dos muitos campos no objeto JSON retornado.

Pode não ser óbvio, mas é importante observar que ExtractVariables produz duas variáveis cujos nomes consistem no prefixo da variável (Geocodingresponse) e do de variáveis especificados na política. Essas variáveis são armazenadas proxy de API e estará disponível para outras políticas dentro do fluxo do proxy, como você de ver. As variáveis são:

• geocoderesponse.latitude
• geocoderesponse.longitude

A maior parte do trabalho já está concluída. Criamos uma combinação de três políticas que formam uma a solicitação, chamar uma API de back-end e analisar os dados JSON retornados. Nas etapas finais, vamos alimentar dados dessa parte do fluxo para outra política AttributionMessage, chame o segundo back-end (Google Elevation API) e retorna nossos dados combinados ao desenvolvedor do aplicativo.

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

Se você examinar a Google Elevation API, verá que ela usa dois parâmetros de consulta. A primeira é chamada locations, e o valor dela é a latitude e longitude. (valores separados por vírgula). O outro parâmetro é sensor, que é obrigatório e precisa ser verdadeiro ou falso. O mais importante nesse ponto é que a solicitação mensagem criada aqui não requer um Service callout. Não precisamos chamar o segundo a partir de uma ServiceChamada neste ponto porque podemos chamar a API de back-end a partir do objeto o TargetEndpoint. Temos todos os dados necessários para chamar o Google Elevations API. A mensagem de solicitação gerada nesta etapa não requer um ServiceCall, já que o gerada para o pipeline de solicitação principal e, portanto, será simplesmente encaminhado pelo ProxyEndpoint ao TargetEndpoint, seguindo a RouteRule configurada para este proxy de API. O TargetEndpoint gerencia a conexão com a API remota. Lembre-se de que o URL do URL A API Elevation está definida na HTTPConnection do TargetEndpoint. API Elevation documentação se quiser saber mais. O QueryParams que armazenamos anteriormente, country e postalcode não são mais necessárias. Por isso, elas foram removidas. aqui.

Breve pausa: de volta ao fluxo

Agora você pode se perguntar por que não estamos criando outra política de Service callout. Depois criamos outra mensagem. Como essa mensagem é enviada para o alvo, a equipe do Google API Elevation? A resposta está no conjunto <RouteRule> elemento do fluxo. &lt;RouteRule&gt; especifica o que fazer com as mensagens de solicitação restantes após a <Request> parte de o fluxo foi executado. O TargetEndpoint especificado por esta <RouteRule> diz ao proxy de API para entregar a mensagem para http://maps.googleapis.com/maps/api/elevation/xml.

Se você tiver feito o download do proxy de API de exemplo, poderá encontrar o XML do TargetProxy no arquivo 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>

Agora, só precisamos processar a resposta da API do Google Elevation e vamos feito.

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

A resposta inclui a localização geocodificada do centro do código postal fornecido por o usuário final do aplicativo, combinado com a elevação nesse local geocodificado. Os dados eram recuperado de duas APIs de back-end, combinado com políticas anexadas ao proxy de API e ao cliente em uma única resposta.

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

Resumo

Este tópico do manual explicou como usar o padrão de composição da política para criar um mashup de dados de várias fontes de back-end. A composição de políticas é um padrão comum usado em APIs desenvolvimento de proxy para adicionar a funcionalidade do criativo à sua API.