Utilizzo della composizione dei criteri

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

Di seguito è riportata una breve descrizione degli elementi che compongono queste norme. Puoi scoprire di più al riguardo nella sezione Assegna Criteri relativi ai messaggi.

• <AssignMessage name>: assegna un nome al criterio. Il nome è utilizzata quando viene fatto riferimento al criterio in un flusso.
• &lt;AssignTo&gt; - Crea una variabile con nome GeocodingRequest. Questa variabile incapsula l'oggetto di richiesta che verrà inviato al backend dal ServiceCallout.
• &lt;QueryParams&gt; - Imposta i parametri di query richiesti dal parametro chiamata API backend. In questo caso, l'API Geocoding deve conoscere la posizione, ovvero espresso con un codice postale e un ID paese. L'utente dell'app fornisce queste informazioni e lo estraiamo qui. Il parametro sensor è richiesto dall'API e viene true o false e l'impostazione come hardcoded qui è false.
• &lt;Verb&gt; - In questo caso, stiamo effettuando una semplice richiesta GET al tramite Google Cloud CLI o tramite l'API Compute Engine.
• &lt;AssignVariable&gt;: queste variabili memorizzano i valori a cui passare all'API. In questo esempio, potrai accedere alle variabili in un secondo momento nella risposta restituiti al cliente.

Invia la richiesta con ServiceCallout

Il passaggio successivo nella sequenza di composizione della norma prevede la creazione di una norma ServiceCallout. La Il criterio ServiceCallout (elenco di seguito) invia l'oggetto della richiesta che abbiamo creato nella precedente criterio AttributionMessage al servizio Google Geocoding e salva il risultato chiamata GeocodingResponse.

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

Di seguito è riportata una breve descrizione degli elementi di questa norma.

• &lt;ServiceCallout&gt; - Come per il criterio precedente, questo ha un .
• <Richiedi variabile> - Questa è la variabile creata in il criterioAssignMessage. Incapsula la richiesta indirizzata all'API backend.
• &lt;Response&gt; - Questo elemento nomina una variabile in cui la risposta viene archiviato. Come vedrai, gli attributi ExtractVariables accederanno a questa variabile in un secondo momento .
• &lt;HTTPTargetConnection&gt; - Specifica l'URL di destinazione del backend tramite Google Cloud CLI o tramite l'API Compute Engine. In questo caso, specifichiamo che l'API restituisce una risposta in formato JSON.

Ora abbiamo due criteri, uno che specifica le informazioni di richiesta necessarie per utilizzare l'API backend (l'API Geocoding di Google) e la seconda che invia effettivamente la richiesta l'API backend. Dopodiché ci occuperemo della risposta.

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

Gli elementi chiave del criterio ExtractVariable sono:

• <ExtractVariables name> - Anche in questo caso, il nome del criterio è utilizzato per fare riferimento al criterio quando viene usato in un flusso.
• &lt;Source&gt; - Specifica la variabile di risposta che abbiamo creato in il criterio ServiceCallout. Questa è la variabile da cui il criterio estrae i dati.
• &lt;VariablePrefix&gt; - Il prefisso della variabile specifica uno spazio dei nomi per ad altre variabili create in questo criterio. Il prefisso può essere qualsiasi nome, ad eccezione di quello riservato i nomi definiti dagli sviluppatori Edge predefinite.
• &lt;JSONPayload&gt;: questo elemento recupera i dati di risposta che vengono di interesse per noi e li inserisce in variabili con nome. Infatti, l'API Geocoding restituisce molte più informazioni rispetto a latitudine e longitudine. Tuttavia, questi sono gli unici valori di cui abbiamo bisogno per questo esempio. Puoi vedere un rendering completo del file JSON restituito dall'API Geocoding nell'interfaccia utente documentazione. I valori di Geometria.location.lat e Geometria.location.lng sono semplicemente due dei molti campi nell'oggetto JSON restituito.

Potrebbe non essere ovvio, ma è importante vedere che ExtractVariables produce due variabili i cui nomi sono costituiti dal prefisso della variabile (codici geografici) e dal numero i nomi delle variabili specificati nel criterio. Queste variabili vengono memorizzate proxy API e sarà disponibile per altri criteri all'interno del flusso di proxy, come vedere. Le variabili sono:

• geocoderesponse.latitude
• geocoderesponse.longitude

La maggior parte del lavoro è ormai fatta. Abbiamo creato tre norme che formano un richiesta, chiamare un'API backend e analizzare i dati JSON restituiti. Negli ultimi passaggi, di dati da questa parte del flusso a un altro criterioAssignMessage, chiama il secondo backend API (API Google Elevation) e restituire i dati combinati allo sviluppatore dell'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>

Se esamini l'API Google Elevation, vedrai che richiede due parametri di query. Il primo si chiama locations e il suo valore sono la latitudine e la longitudine (valori separati da virgole). L'altro parametro è sensor, che è obbligatorio e deve true o false. La cosa più importante da notare a questo punto è che la richiesta che creiamo qui non richiede ServiceCallout. Non è necessario chiamare il secondo API da un ServiceCallout a questo punto perché possiamo chiamare l'API backend dal Endpoint di destinazione. A pensarci bene, abbiamo tutti i dati necessari per chiamare il programma Google Elevations API Il messaggio di richiesta generato in questo passaggio non richiede un ServiceCallout, poiché generata per la pipeline di richiesta principale, quindi verrà inoltrata semplicemente ProxyEndpoint al TargetEndpoint, seguendo la RouteRule configurata per questo proxy API. TargetEndpoint gestisce la connessione con l'API remota. Ricorda che l'URL relativo l'API elevazione è definita nella HTTPConnection per TargetEndpoint. API Elevation documentazione se vuoi saperne di più. I parametri QueryParam archiviati in precedenza, country e postalcode non sono più necessari, perciò li rimuoviamo qui.

Breve pausa: torna al flusso

A questo punto, potresti chiederti perché non stiamo creando un'altra norma ServiceCallout. Dopo il giorno tutti, abbiamo creato un altro messaggio. In che modo il messaggio viene inviato alla destinazione, l'account Google API Elevation? La risposta è nella regola <RouteRule> elemento del flusso. &lt;RouteRule&gt; specifica cosa fare con gli eventuali messaggi di richiesta rimanenti dopo il tag <Request> parte di eseguito il flusso. Il TargetEndpoint specificato da questa <RouteRule> indica Proxy API per la consegna del messaggio a http://maps.googleapis.com/maps/api/elevation/xml.

Se hai scaricato il proxy API di esempio, puoi trovare il file XML TargetProxy nel file 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>

Ora dobbiamo solo elaborare la risposta dell'API Google Elevation e fatto.

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

La risposta include la posizione geocodificata per il centro del codice postale fornito da l'utente finale dell'app, combinata con l'altitudine della posizione geocodificata. I dati erano recuperate da due API di backend, combinate con criteri collegati al proxy API, al client in un'unica risposta.

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

Riepilogo

L'argomento del libro di ricette spiega come utilizzare il pattern di composizione dei criteri per creare un mashup di dati provenienti da più origini backend. La composizione dei criteri è un pattern comune utilizzato nell'API sviluppo di proxy per aggiungere funzionalità della creatività all'API.