정책 구성 사용

<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 호출에 필요한 쿼리 매개변수를 설정합니다. 이 경우 Geocoding API는 우편번호와 국가 ID로 표현되는 위치를 알아야 합니다. 앱 사용자가 이 정보를 제공하며 여기에서 이 정보를 추출하기만 하면 됩니다. sensor 매개변수는 API에 필요하며 true 또는 false입니다. 여기서는 false로 하드코딩합니다.
• <Verb> - 이 경우 API에 간단한 GET 요청을 수행합니다.
• <AssignVariable> - 이러한 변수는 API에 전달하는 값을 저장합니다. 이 예시에서는 변수가 나중에 클라이언트에 반환된 응답 에서 액세스됩니다.

ServiceCallout으로 요청 전송

정책 구성 시퀀스의 다음 단계는 ServiceCallout 정책을 만드는 것입니다. 아래에 나열된 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>

다음은 이 정책의 요소에 대한 간략한 설명입니다.

• <ServiceCallout> - 이전 정책과 마찬가지로 이 정책에도 이름이 있습니다.
• <Request variable> - AssignMessage 정책에서 만든 변수입니다. 백엔드 API로 이동하는 요청을 캡슐화합니다.
• <Response> - 이 요소는 응답이 저장되는 변수의 이름을 지정합니다. 이 변수는 나중에 ExtractVariables 정책에서 액세스됩니다.
• <HTTPTargetConnection> - 백엔드 API의 대상 URL을 지정합니다. 이 경우 API가 JSON 응답을 반환하도록 지정합니다.

이제 백엔드 API (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> - 다시 말하지만 정책 이름은 흐름에서 사용될 때 정책을 참조하는 데 사용됩니다.
• <Source> - ServiceCallout 정책에서 만든 응답 변수를 지정합니다. 이 정책이 데이터를 추출하는 변수입니다.
• <VariablePrefix> - 변수 프리픽스는 이 정책에서 만든 다른 변수의 네임스페이스를 지정합니다. 프리픽스는 Edge's 사전 정의된 변수에서 정의한 예약된 이름을 제외한 모든 이름이 될 수 있습니다.
• <JSONPayload> - 이 요소는 관심 있는 응답 데이터를 가져와서 이름이 지정된 변수에 넣습니다. 실제로 Geocoding API는 위도와 경도보다 훨씬 많은 정보를 반환합니다. 하지만 이 샘플에는 이러한 값만 필요합니다. Geocoding API에서 반환된 JSON의 전체 렌더링은 API의 문서에서 확인할 수 있습니다. geometry.location.lat 및 geometry.location.lng의 값은 반환된 JSON 객체의 여러 필드 중 두 개일 뿐입니다.

명확하지 않을 수 있지만 ExtractVariables는 이름이 변수 프리픽스 (geocoderesponse)와 정책에 지정된 실제 변수 이름으로 구성된 두 변수를 생성한다는 점을 확인하는 것이 중요합니다. 이러한 변수는 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이 필요하지 않다는 것입니다. 이 시점에서는 ServiceCallout에서 두 번째 API를 호출할 필요가 없습니다. 프록시의 TargetEndpoint에서 백엔드 API를 호출할 수 있기 때문입니다. 생각해 보면 Google Elevations API를 호출하는 데 필요한 모든 데이터가 있습니다. 이 단계에서 생성된 요청 메시지에는 ServiceCallout이 필요하지 않습니다. 기본 요청 파이프라인에 대해 생성된 요청이므로 이 API 프록시에 구성된 RouteRule에 따라 ProxyEndpoint에서 TargetEndpoint로 전달되기만 하면 됩니다. TargetEndpoint는 Remote API와의 연결을 관리합니다. Elevation API의 URL은 TargetEndpoint의 HTTPConnection에 정의되어 있습니다. 자세한 내용은 Elevation API 문서를 참조하세요. 이전에 저장한 QueryParams인 country와 postalcode는 더 이상 필요하지 않으므로 여기에서 삭제합니다.

잠시 멈춤: 흐름으로 돌아가기

이 시점에서 다른 ServiceCallout 정책을 만들지 않는 이유가 궁금할 수 있습니다. 결국 다른 메시지를 만들었습니다. 이 메시지는 대상인 Google Elevation API로 어떻게 전송되나요? 답은 흐름의 <RouteRule> 요소에 있습니다. <RouteRule> 흐름의 <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에 창의적인 기능을 추가하기 위해 사용되는 일반적인 패턴입니다.