Korzystanie z kompozycji zasad

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

Oto krótki opis elementów tych zasad. Więcej informacji znajdziesz zasady w sekcji Przypisz Zasady dotyczące wiadomości.

• <AssignMessage name> – nadaje tej zasadzie nazwę. Nazwa to używana, gdy do zasady odwołuje się przepływ.
• &lt;AssignTo&gt; – tworzy zmienną nazwaną o nazwie GeocodingRequest. Ta zmienna zawiera obiekt żądania, który zostanie wysłany do backendu przez Zasady dotyczące wywołań usługi.
• &lt;QueryParams&gt; – ustawia parametry zapytania wymagane przez wywołanie interfejsu API backendu. W tym przypadku interfejs Geocoding API musi znać lokalizację, która jest wyrażony za pomocą kodu pocztowego oraz identyfikatora kraju. użytkownik aplikacji poda te informacje, po prostu wyodrębnimy go tutaj. Parametr sensor jest wymagany przez interfejs API. czyli prawda lub fałsz, i zakodujemy go na stałe jako fałsz.
• &lt;Verb&gt; – w tym przypadku wysyłamy proste żądanie GET do funkcji API.
• &lt;AssignVariable&gt; – te zmienne przechowują wartości i przekazywać je do interfejsu API. W tym przykładzie dostęp do zmiennych uzyskamy później w odpowiedzi klientowi.

Wyślij żądanie z objaśnieniem usługi

Następnym krokiem w sekwencji kompozycji zasad jest utworzenie zasady ServiceCallout. Zasada ServiceCallout, wymieniona poniżej, wysyła obiekt żądania utworzony w poprzednia zasada AssignMessage do usługi Google Geocoding, a wynik jest zapisywany w pliku o nazwie GeocodingResponse.

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

Oto krótki opis tych zasad.

• &lt;ServiceCallout&gt; – tak jak w poprzednich zasadach, w tym przypadku obowiązują imię i nazwisko.
• <Request zmienna> – to zmienna utworzona w zasady AssignMessage. Obejmuje żądanie kierowane do interfejsu API backendu.
• &lt;Response&gt; – ten element zawiera nazwę zmiennej, w której odpowiedź . Jak widać, dostęp do tej zmiennej będzie później uzyskiwać .
• &lt;HTTPTargetConnection&gt; – określa docelowy adres URL backendu API. W tym przypadku określamy, że interfejs API zwraca odpowiedź JSON.

Mamy teraz dwie zasady. Pierwsza określa żądane informacje, które są niezbędne API backendu (interfejs Geocoding API Google) oraz drugi, który faktycznie wysyła żądanie do lub interfejs API backendu. Teraz zajmiemy się odpowiedziami.

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

Kluczowe elementy zasady Extractzmiennej to:

• <Extractvariables name> – nazwa zasady służy też do tego, odwołują się do zasady, gdy jest ona używana w ramach przepływu.
• &lt;Source&gt; – określa zmienną odpowiedzi, która została utworzona w zasad dotyczących wywołań usług. To jest zmienna, z której ta zasada wyodrębnia dane.
• &lt;VariablePrefix&gt; – prefiks zmiennej określa przestrzeń nazw dla innych zmiennych utworzonych w tej zasadzie. Prefiks może być dowolną nazwą oprócz zarezerwowanego nazwy zdefiniowane przez Edge's wstępnie zdefiniowanych zmiennych.
• &lt;JSONPayload&gt; – ten element pobiera dane odpowiedzi, które są i umieszcza je w nazwanych zmiennych. Interfejs Geocoding API zwraca ma więcej informacji niż szerokość i długość geograficzną. Są to jednak jedyne wartości, jakich potrzebujemy, dla tego przykładu. Możesz zobaczyć pełne wyrenderowanie kodu JSON zwróconego przez Geocoding API w interfejsie API dokumentacji. Wartości geometry.location.lat i geometry.location.lng to po prostu 2 z wielu pól w zwróconym obiekcie JSON.

Może to nie być oczywiste, ale ważne jest, aby zauważyć, że funkcja Extractvariables daje dwie wartości: zmiennych, których nazwy składają się z prefiksu zmiennej (odpowiedź geokodowa) i rzeczywistej wartości nazw zmiennych określonych w zasadzie. Te zmienne są przechowywane w sekcji API i będą dostępne dla innych zasad w procesie serwera proxy, podobnie jak zobaczyć. Zmienne to:

• geocoderesponse.latitude
• geocoderesponse.longitude

Większość pracy masz już za sobą. Utworzyliśmy zestaw trzech zasad, które tworzą żądania, wywołaj interfejs API backendu i przeanalizuj zwrócone dane JSON. Na koniec dodamy danych z tej części przepływu do innej zasady AssignMessage, wywołaj drugi backend API (Google Elevation API) i zwracają połączone dane deweloperowi aplikacji.

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

Po zapoznaniu się z interfejsem Google Elevation API zauważysz, że wymaga on 2 parametrów zapytania. Pierwsza ma nazwę locations, a jej wartość to szerokość i długość geograficzna. (wartości rozdzielone przecinkami). Drugi parametr to sensor, który jest wymagany i musi być typu prawda lub fałsz. Najważniejszą rzeczą, o której należy pamiętać, jest to, że prośba utworzona przez nas wiadomość nie wymaga objaśnienia dotyczącego usługi. Nie musimy dzwonić do drugiej API z funkcji ServiceCallout w tym momencie, ponieważ możemy wywołać interfejs API backendu z serwera proxy Docelowy punkt końcowy. Mamy wszystkie dane potrzebne do nazywania Google Elevations. API Komunikat żądania wygenerowany w tym kroku nie wymaga objaśnienia Service, ponieważ dla głównego potoku żądań i są po prostu przekazywane przez ProxyEndpoint do docelowego punktu końcowego zgodnie z regułą trasy skonfigurowaną dla tego serwera proxy interfejsu API. Element TargetEndpoint zarządza połączeniem ze zdalnym interfejsem API. (Pamiętaj, że adres URL Interfejs API podniesienia uprawnień jest zdefiniowany w interfejsie HTTPConnection dla docelowego punktu końcowego. Interfejs API Elevation dokumentacji, jeśli chcesz uzyskać więcej informacji. Zapisane wcześniej parametry QueryParams country i postalcode nie są już potrzebne, dlatego je usuwamy tutaj.

Krótkie wstrzymanie: powrót do historii

W tym momencie możesz się zastanawiać, dlaczego nie tworzymy kolejnych zasad dotyczących wywołań usług. Po Utworzyliśmy kolejną wiadomość. W jaki sposób ta wiadomość jest wysyłana do grupy docelowej Interfejs Elevation API? Odpowiedź znajdziesz w tagu <RouteRule> pewnego elementu ścieżki. &lt;RouteRule&gt; określa, co zrobić z pozostałymi komunikatami żądania po żądaniu <Request>. część który wykonano w późniejszym czasie. Docelowy punkt końcowy określony przez tę regułę <RouteRule> informuje Serwer proxy interfejsu API dostarczający wiadomość do http://maps.googleapis.com/maps/api/elevation/xml.

Jeśli pobrałeś przykładowy serwer proxy interfejsu API, jego kod XML znajdziesz w pliku 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>

Teraz musimy tylko przetworzyć odpowiedź z interfejsu Google Elevation API gotowe.

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

Odpowiedź zawiera geokodowaną lokalizację centrum kodu pocztowego podaną przez użytkownika aplikacji w połączeniu z wysokością w danej lokalizacji geograficznej. Dane były pobierane z 2 interfejsów API backendu, połączone z zasadami dołączonymi do serwera proxy API oraz zwracane klientowi w pojedynczej odpowiedzi.

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

Podsumowanie

Z tej książki kucharskiej dowiesz się, jak wykorzystać wzorzec kompozycji zasad do stworzenia mashupów danych z wielu źródeł zaplecza. Kompozycja zasad to typowy wzorzec używany w interfejsach API programowanie proxy w celu dodania funkcji kreacji do interfejsu API.