使用政策构成

<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 的命名变量。 此变量用于封装将由 ServiceCallout 政策。
• &lt;QueryParams&gt; - 设置 后端 API 调用。在本例中，Geocoding API 需要知道位置， 用邮政编码和国家/地区 ID 表示。这类信息由应用用户提供 我们只需在此处提取数据即可API 需要使用 sensor 参数， 可以将其硬编码为 false。
• &lt;Verb&gt; - 在本示例中，我们会向 API。
• &lt;AssignVariable&gt; - 这些变量用于存储 传递给 API。在本例中，稍后将在响应中访问变量 返回给客户端

使用 ServiceCallout 发送请求

政策组合序列中的下一步是创建 ServiceCallout 政策。通过 下面列出的 ServiceCallout 政策会发送我们在 将之前的 AssignMessage 政策添加到 Google 地理编码服务，并将结果保存在 变量。

<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 variable> - 这是在 AssignMessage 政策它会封装发送到后端 API 的请求。
• &lt;Response&gt; - 此元素为用来指定响应的变量 。如您所见，ExtractVariables 稍后会访问此变量 政策。
• &lt;HTTPTargetConnection&gt; - 指定后端的目标网址 API。在本例中，我们指定 API 返回 JSON 响应。

现在我们有两项政策，一项用于指定使用 后端 API（Google 的 Geocoding API），而第二种 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; - 指定在 ServiceCallout 政策。这是此政策从中提取数据的变量。
• &lt;VariablePrefix&gt; - 变量前缀指定用于 创建的其他变量前缀可以是任何名称，但预留名称除外 由 Edge 的 预定义变量。
• &lt;JSONPayload&gt; - 此元素用于检索 并将其放入命名变量中。事实上，Geocoding API 会返回很多 比经纬度多的信息。不过，我们只需要这些值 示例。您可以看到 Geocoding API 返回的 JSON 的完整渲染 位于 API 的 文档。geo.location.lat 和 metry.location.lng 的值就是 是所返回的 JSON 对象中众多字段中的两个。

这可能并不明显，但重要的是，ExtractVariables 会生成两个 变量，其名称由变量前缀 (Geocodingresponse) 和实际 变量名称。这些变量存储在 API 代理，并且可用于代理流程中的其他政策， 看到的内容。变量为：

• 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，会发现它采用了两个查询参数。 第一个名为 locations，其值是纬度和经度 （逗号分隔值）。另一个参数是 sensor，该参数是必需参数，必须 为 true 或 false。此时，需要注意的最重要的一点是 我们在这里创建的消息不需要 ServiceCallout。我们无需调用第二个 API，因为我们可以从代理的 TargetEndpoint。仔细想想，我们已经拥有调用 Google 海拔所需的全部数据。 API 在此步骤中生成的请求消息不需要 ServiceCallout，因为 为主请求管道生成的请求，因此只会由 按照为此 API 代理配置的 RouteRule 从 ProxyEndpoint 到 TargetEndpoint。 TargetEndpoint 管理与远程 API 的连接。（您应该还记得 Elevation API 在 TargetEndpoint 的 HTTPConnection 中定义。Google Elevation API 文档。我们之前存储的 QueryParams， 由于不再需要 country 和 postalcode，因此我们会将其移除 此处。

短暂停顿：返回到流程

现在，您可能想知道我们为什么不创建另一个 ServiceCallout 政策。更新后 我们又创建了一条消息如何将该信息发送给目标 Elevation API？答案就在 <RouteRule> 中流的元素。&lt;RouteRule&gt; 指定如何处理 <Request> 之后的所有剩余请求消息属于 流的执行情况。此 <RouteRule> 指定的 TargetEndpoint>会告诉 用于传送消息的 API 代理 发送至 http://maps.googleapis.com/maps/api/elevation/xml。

如果您下载了示例 API 代理，则可以在文件中找到 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 代理的政策相混淆；以及 在单个响应中返回给客户端

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

摘要

本实战宝典主题介绍了如何使用策略组合模式创建混搭 来自多个后端来源的数据。政策组合是 API 中使用的一种常见模式 代理开发，以便向您的 API 添加广告素材功能。