Richtlinienzusammensetzung verwenden

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

Nachfolgend finden Sie eine kurze Beschreibung der Elemente dieser Richtlinie. Weitere Informationen zu diesem Thema in Nachrichtenrichtlinie:

• <AssignMessage name> – gibt dieser Richtlinie einen Namen. Der Name lautet wird verwendet, wenn in einem Ablauf auf die Richtlinie verwiesen wird.
• &lt;AssignTo&gt;: Erstellt eine benannte Variable namens „GeocodingRequest“. Diese Variable schließt das Anfrageobjekt ein, das vom ServiceCallout-Richtlinie.
• &lt;QueryParams&gt;: Legt die Abfrageparameter fest, die von den Back-End-API-Aufrufs. In diesem Fall muss das Geocoding API den Standort kennen, also mit einer Postleitzahl und einer Länder-ID. Der App-Nutzer stellt diese Informationen bereit extrahieren wir sie hier. Der Parameter sensor ist für die API erforderlich und „true“ oder „false“ verwenden, und wir haben es nur mit „false“ hartcodiert.
• &lt;Verb&gt;: In diesem Fall stellen wir eine einfache GET-Anfrage an die der API erstellen.
• &lt;AssignVariable&gt; - Diese Variablen speichern die Werte, die wir verwenden. die an die API übergeben werden. In diesem Beispiel wird später in der Antwort auf die Variablen zugegriffen. an den Client zurückgegeben.

Anfrage mit ServiceCallout senden

Im nächsten Schritt der Reihenfolge der Richtlinienzusammensetzung erstellen Sie eine ServiceCallout-Richtlinie. Die Die unten aufgeführte ServiceCallout-Richtlinie sendet das Anfrageobjekt, das wir im an den Google Geocoding-Dienst an und speichert das Ergebnis in einem GeocodingResponse aufgerufen werden.

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

Nachfolgend finden Sie eine kurze Beschreibung der Elemente dieser Richtlinie.

• &lt;ServiceCallout&gt; – Wie die vorherige Richtlinie hat diese Richtlinie Namen.
• <Anfragevariable> – Variable, die in der Richtlinie „AssignMessage“ zugewiesen. Er kapselt die Anfrage, die an die Back-End-API geht.
• &lt;Response&gt; - Dieses Element gibt eine Variable an, in der die Antwort gespeichert ist. Wie Sie sehen werden, greift ExtractVariables später auf diese Variable zu. .
• &lt;HTTPTargetConnection&gt; – Gibt die Ziel-URL des Back-Ends an der API erstellen. In diesem Fall geben wir an, dass die API eine JSON-Antwort zurückgibt.

Jetzt gibt es zwei Richtlinien: In der einen sind die Informationen angegeben, die für die Nutzung des Back-End-API (Geocoding API von Google) und das zweite, das die Anfrage tatsächlich an die Back-End-API. Als Nächstes bearbeiten wir die Antwort.

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

Die Hauptelemente der ExtractVariable-Richtlinie sind:

• <ExtractVariables name>: Auch hier wird der Richtlinienname dazu verwendet, auf die Richtlinie verweisen, wenn sie in einem Ablauf verwendet wird.
• &lt;Source&gt;: Gibt die Antwortvariable an, die in erstellt wurde. ServiceCallout-Richtlinie. Dies ist die Variable, aus der diese Richtlinie Daten extrahiert.
• &lt;VariablePrefix&gt; - Das Variablenpräfix gibt einen Namespace für anderen in dieser Richtlinie erstellten Variablen. Das Präfix kann ein beliebiger Name sein, mit Ausnahme des reservierten Namen definiert durch Edges vordefinierte Variablen.
• &lt;JSONPayload&gt; – Dieses Element ruft die Antwortdaten ab, die und fügt sie in benannte Variablen ein. Tatsächlich gibt die Geocoding API viel zurück, mehr Informationen als Längen- und Breitengrad. Dies sind jedoch die einzigen Werte, die wir benötigen, für dieses Beispiel. Sie können sich ein vollständiges Rendering des von der Geocoding API zurückgegebenen JSON-Objekts ansehen. in den APIs Dokumentation. Die Werte von Geocoding.location.lat und Neugeometrie.location.lng sind einfach zwei der vielen Felder im zurückgegebenen JSON-Objekt.

Es ist vielleicht nicht offensichtlich, aber es ist wichtig zu sehen, dass ExtractVariables Variablen, deren Namen aus dem Variablenpräfix (georesponse) und dem tatsächlichen Variablennamen, die in der Richtlinie angegeben sind. Diese Variablen werden im API-Proxy verwenden und für andere Richtlinien innerhalb des Proxy-Ablaufs verfügbar sein, wie Sie sehen. Die Variablen sind:

• geocoderesponse.latitude
• geocoderesponse.longitude

Der Großteil der Arbeit ist jetzt erledigt. Wir haben drei Richtlinien erstellt, die eine -Anfrage, rufen Sie eine Back-End-API auf und parsen Sie die zurückgegebenen JSON-Daten. In den letzten Schritten Daten aus diesem Teil des Ablaufs in eine andereAssignMessage-Richtlinie übertragen, rufen Sie das zweite Back-End auf API (Google Elevation API) zurück und senden die verpackten Daten an den App-Entwickler.

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

Wenn Sie das Google Elevation API untersuchen, werden Sie feststellen, dass zwei Suchparameter erforderlich sind. Die erste heißt locations und ihr Wert ist der Breiten- und Längengrad. (kommagetrennte Werte). Der andere Parameter ist sensor, der erforderlich ist und entweder wahr oder falsch sein. Das Wichtigste an dieser Stelle ist, dass die Anforderung erstellt wird, ist kein ServiceCallout erforderlich. Wir müssen nicht die zweite API aus einem ServiceCallout heraus, da wir die Back-End API über die Proxy- TargetEndpoint. Wenn Sie darüber nachdenken, verfügen wir über alle Daten, die wir für Google Elevations benötigen. API Die in diesem Schritt generierte Anfragenachricht erfordert kein ServiceCallout, da die -Anfrage generiert, die für die Hauptanfrage-Pipeline generiert wurde, und daher einfach vom ProxyEndpoint zum TargetEndpoint, gemäß der für diesen API-Proxy konfigurierten RouteRule. Der TargetEndpoint verwaltet die Verbindung mit der Remote-API. (Die URL für die Die Elevation API wird in der HTTPConnection für den TargetEndpoint definiert. Elevation API Dokumentation, wenn Sie mehr erfahren möchten. Mit den zuvor gespeicherten QueryParams country und postalcode werden nicht mehr benötigt, daher entfernen wir sie hier.

Kurze Pause: Zurück zum Ablauf

Sie fragen sich jetzt vielleicht, warum wir keine weitere ServiceCallout-Richtlinie erstellen. Nachher haben wir eine weitere Nachricht erstellt. Wie wird diese Nachricht an das Ziel, die Google Elevation API? Die Antwort befindet sich in der <RouteRule> -Element des Ablaufs. &lt;RouteRule&gt; gibt an, was mit allen verbleibenden Anfragenachrichten nach der Anfrage <Request> geschehen soll. Teil von der Ablauf ausgeführt wurde. Der in dieser <RouteRule> angegebene TargetEndpoint teilt dem API-Proxy zum Senden der Nachricht an http://maps.googleapis.com/maps/api/elevation/xml.

Wenn Sie den Beispiel-API-Proxy heruntergeladen haben, finden Sie die TargetProxy-XML in der Datei 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>

Jetzt müssen wir nur noch die Antwort des Google Elevation APIs verarbeiten fertig.

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

Die Antwort enthält die geocodierte Position in der Mitte der Postleitzahl, die von den Endnutzer der App, kombiniert mit der Höhe dieses geocodierten Standorts. Die Daten waren die von zwei Back-End-APIs abgerufen und mit Richtlinien verknüpft sind, die an den API-Proxy angehängt sind, und die in einer einzigen Antwort an den Client zurückgegeben werden.

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

Zusammenfassung

In diesem Kochbuch-Thema wurde erklärt, wie du mithilfe des Musters zum Zusammensetzen der Richtlinien ein Mashup erstellen kannst. von Daten aus mehreren Back-End-Quellen. Die Richtlinienzusammensetzung ist ein gängiges Muster in der API. Proxy-Entwicklung zum Hinzufügen von Creative-Funktionen zu Ihrer API.