Использование композиции политики

<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> — присваивает этой политике имя. Имя используется, когда на политику ссылаются в потоке.
• <AssignTo> — создает именованную переменную с именем GeocodingRequest. Эта переменная инкапсулирует объект запроса, который будет отправлен на серверную часть политикой ServiceCallout.
• <QueryParams> — устанавливает параметры запроса, необходимые для вызова внутреннего API. В этом случае API геокодирования необходимо знать местоположение, выраженное почтовым индексом, и идентификатор страны. Пользователь приложения предоставляет эту информацию, и мы просто извлекаем ее здесь. Параметр sensor требуется API и имеет либо истинное, либо ложное значение, и здесь мы просто жестко запрограммировали его как ложное.
• <Verb> — в данном случае мы делаем простой GET-запрос к API.
• <AssignVariable> — эти переменные хранят значения, которые мы передаем в API. В этом примере доступ к переменным будет осуществляться позже в ответе, возвращаемом клиенту.

Отправьте запрос с помощью ServiceCallout

Следующим шагом в последовательности создания политики является создание политики ServiceCallout . Политика ServiceCallout, указанная ниже, отправляет объект запроса, который мы создали в предыдущей политике AssignMessage, в службу геокодирования Google и сохраняет результат в переменной с именем GeocodingResponse.

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

Вот краткое описание элементов этой политики.

• <ServiceCallout> — как и в предыдущей политике, у этой политики есть имя.
• <Переменная запроса> — это переменная, созданная в политике AssignMessage. Он инкапсулирует запрос, поступающий к серверному API.
• <Response> — этот элемент называет переменную, в которой хранится ответ. Как вы увидите, эта переменная будет доступна позже для политики ExtractVariables.
• <HTPTTargetConnection> — указывает целевой URL-адрес внутреннего API. В этом случае мы указываем, что API возвращает ответ JSON.

Теперь у нас есть две политики: одна определяет информацию запроса, необходимую для использования внутреннего API (API геокодирования Google), а вторая фактически отправляет запрос во внутренний 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> — опять же, имя политики используется для ссылки на политику, когда она используется в потоке.
• <Source> — указывает переменную ответа, которую мы создали в политике ServiceCallout. Это переменная, из которой эта политика извлекает данные.
• <VariablePrefix> — префикс переменной указывает пространство имен для других переменных, созданных в этой политике. Префиксом может быть любое имя, за исключением зарезервированных имен, определенных предопределенными переменными Edge .
• <JSONPayload> — этот элемент извлекает интересующие нас данные ответа и помещает их в именованные переменные. Фактически, API геокодирования возвращает гораздо больше информации, чем широту и долготу. Однако это единственные значения, которые нам нужны для этого образца. Полную визуализацию JSON, возвращаемого API геокодирования, можно увидеть в документации API . Значения Geometry.location.lat и Geometry.location.lng — это просто два из многих полей в возвращаемом объекте JSON.

Это может быть неочевидно, но важно видеть, что ExtractVariables создает две переменные, имена которых состоят из префикса переменной (геокодерепонс) и фактических имен переменных, указанных в политике. Эти переменные хранятся в прокси-сервере API и, как вы увидите, будут доступны другим политикам в потоке прокси-сервера. Переменные:

• geocoderesponse.latitude
• geocoderesponse.longitude

Большая часть работы уже сделана. Мы создали совокупность трех политик, которые формируют запрос, вызывают внутренний API и анализируют возвращаемые данные JSON. На последних шагах мы передадим данные из этой части потока в другую политику AssignMessage, вызовем второй серверный API (API Google Elevation) и вернем смешанные данные разработчику приложения.

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

Если вы изучите API Google Elevation, вы увидите, что он принимает два параметра запроса. Первый называется locations , и его значением является широта и долгота (значения, разделенные запятыми). Другой параметр — sensor , который является обязательным и должен иметь значение true или false. Самое важное, что следует отметить на этом этапе, — это то, что сообщение запроса, которое мы здесь создаем, не требует ServiceCallout. На этом этапе нам не нужно вызывать второй API из ServiceCallout, поскольку мы можем вызвать внутренний API из TargetEndpoint прокси. Если подумать, у нас есть все данные, необходимые для вызова API Google Elevations. Сообщение запроса, созданное на этом этапе, не требует ServiceCallout, поскольку запрос, сгенерированный для основного конвейера запросов, будет просто перенаправлен ProxyEndpoint. к TargetEndpoint, следуя RouteRule, настроенному для этого прокси API. TargetEndpoint управляет соединением с удаленным API. (Напомним, что URL-адрес API повышения определен в HTTPConnection для TargetEndpoint. Документация по API повышения, если вы хотите узнать больше. QueryParams, которые мы сохранили ранее, country и postalcode , больше не нужны, поэтому мы удаляем их здесь. .

Короткая пауза: Назад в поток

На этом этапе вы можете задаться вопросом, почему мы не создаем еще одну политику ServiceCallout. Ведь мы создали еще одно сообщение. Как это сообщение отправляется в целевой API Google Elevation? Ответ находится в элементе <RouteRule> потока. <RouteRule> указывает, что делать с оставшимися сообщениями запроса после выполнения части <Request> потока. TargetEndpoint, указанный в этом <RouteRule>, указывает прокси-серверу API доставить сообщение в http://maps.googleapis.com/maps/api/elevation/xml .

Если вы загрузили образец прокси-сервера API, вы можете найти XML-файл TargetProxy в файле 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>

Теперь нам просто нужно обработать ответ от API Google Elevation, и все готово.

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