使用政策組合

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

以下簡要說明這項政策的元素。你可以閱讀 指派政策 訊息政策：

• <AssignMessage name>：為這項政策命名。名稱是 在流程中參照政策時使用。
• &lt;AssignTo&gt; - 建立名為 GeocodingRequest 的具名變數。 這個變數會封裝要求物件，此物件將由 服務呼叫政策。
• &lt;QueryParams&gt; - 設定 後端 API 呼叫在此情況下，Geocoding API 必須知道位置， 以郵遞區號和國家/地區 ID 表示應用程式使用者提供這項資訊。 直接在這裡擷取sensor 是 API 的必要參數， 傳回 true 或 false，然後在這裡硬式編碼為 false
• &lt;Verb&gt; - 在這個範例中，我們要向 也能使用 Google Cloud CLI 或 Compute Engine API
• &lt;AssignVariable&gt; - 這些變數會儲存我們 傳遞到 API在本範例中，系統會在稍後在回應中存取變數。 傳回給用戶端。

傳送要求並加上 ServiceCALL

政策組合序列的下一步是建立 ServiceCallout 政策。 服務摘要政策 (列於下方) 會將我們在 舊版 AssignMessage 政策套用至 Google Geocoding 服務，然後將結果儲存在 稱為 GeocodingResponse 的變數。

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

以下簡要說明這項政策的元素。

• &lt;ServiceCallout&gt; - 與先前的政策一樣，這項政策設有 名稱。
• <Request 變數> - 這是建立在 指派訊息政策並封裝傳送至後端 API 的要求。
• &lt;Response&gt; - 此元素會為回應命名 資料。如您所見，稍後您可以透過 ExtractVariables 存取這個變數 政策。
• &lt;HTTPTargetConnection&gt;：指定後端的目標網址 也能使用 Google Cloud CLI 或 Compute Engine API在這個範例中，我們會指定 API 傳回 JSON 回應。

現在我們有兩個政策，一項指定使用 Google 的 Geocoding API)，第二個則是實際將要求傳送至 與後端 API 通訊接著，我們會處理回應。

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

ExtractVariable 政策的主要元素如下：

• <ExtractVariables name>：同樣會將政策名稱用於 如果是在流程中使用政策，就會參照該政策。
• &lt;Source&gt;：指定我們在 服務呼叫政策。這是這項政策用來擷取資料的變數。
• &lt;VariablePrefix&gt; - 變數前置字串會為 政策中建立的其他變數。前置字串可以是任何名稱，但保留名稱除外 由 Edge 的 預先定義的變數
• &lt;JSONPayload&gt; - 這個元素會擷取 並放入具名變數中事實上，Geocoding API 會傳回很多 而不是經緯度的資訊不過，這些是我們只需要 範例。您可以看到 Geocoding API 傳回的 JSON 完整呈現方式 API 的 說明文件。geo.location.lat 和 geo.location.lng 的值只是 傳回 JSON 物件的兩個欄位。

乍看之下， ExtractVariables 會產生兩個 名稱由變數前置字元 (Geocodingresponse) 和實際 政策中指定的變數名稱。這些變數會儲存在 API Proxy，也會在 Proxy 流程中適用於其他政策，就像您將會 請參閱變數如下：

• geocoderesponse.latitude
• geocoderesponse.longitude

大部分工作都已經完成，我們根據三項政策 要求、呼叫後端 API，以及剖析傳回的 JSON 資料。在最後的步驟中 這個流程中的資料傳送到另一個 AssignMessage 政策時，會呼叫第二個後端 API (Google Elevation API)，然後將經過混和的資料傳回給應用程式開發人員。

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

查看 Google Elevation API 時，您會發現該 API 使用兩個查詢參數。 第一個參數稱為 locations，其值是經緯度 (逗號分隔值)。另一個參數是 sensor，這是必要參數，且必須 可以是 true 或 false。此時最重要的一點是 我們在這裡建立的訊息不需要服務呼叫我們無須在 API 從 Service 呼叫 發出，因為我們可從 Proxy 的 TargetEndpoint，仔細想想，我們有呼叫 Google Elevations 所需的所有資料 這個步驟產生的要求訊息不需要 Service 子女，因為 完全由主要要求管道產生的要求，因此會直接由 按照為這個 API Proxy 設定的 RouteRule，將 ProxyEndpoint 傳送至 TargetEndpoint。 TargetEndpoint 會管理與遠端 API 的連線。(請注意， 並在 TargetEndpoint 的 HTTPConnection 中定義 elevation API。Elevation API 。先前儲存的 QueryParams 不再需要「country」和「postalcode」，因此我們會將其移除 此處。

簡短停頓：返回流程

您現在可能會好奇，為何我們不建立另一項服務呼叫政策。更新後 我們又建立了一則訊息如何將訊息傳送給目標；Google Elevation API？答案就在 <RouteRule> 中流程的各個元素&lt;RouteRule&gt; 指定如何處理 <Request> 後所有剩餘的要求訊息部分 流程就會執行這個 <RouteRule> 指定的 TargetEndpoint告知 用來傳送訊息的 API Proxy 至 http://maps.googleapis.com/maps/api/elevation/xml。

如果您下載了範例 API Proxy，您可以在檔案中找到 TargetProxy XML 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>

現在我們只需處理 Google Elevation API 的回應， 完成。

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

回應中會包含由 應用程式使用者，結合該地理編碼位置的海拔高度。資料之前為 擷取自兩個後端 API，並與附加至 API Proxy 的政策混搭，以及 透過單一回應傳回用戶端。

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

摘要

本教戰手冊主題說明如何使用政策組成模式來建立混搭 來自多個後端來源的資料政策組成是 API 使用的常見模式 透過 Proxy 開發，將廣告素材功能新增至 API。