Warunki ze zmiennymi przepływu

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Instrukcje warunkowe to powszechna struktura kontrolna we wszystkich językach programowania. Podobne do języka programowania, konfiguracja serwera proxy API obsługuje instrukcje warunkowe dla Flows, Zasady, kroki i reguły trasy. Definiując instrukcje warunkowe, definiujesz zachowanie dynamiczne dla swojego interfejsu API. To dynamiczne zachowanie pozwala np. konwertować zawartość pliku XML na format JSON tylko w przypadku telefony komórkowe lub kierowanie na URL backendu na podstawie typu treści lub czasownika HTTP żądania. .

Z tego artykułu dowiesz się, jak używać warunków do dynamicznego stosowania funkcji zarządzania interfejsami API w: środowiska wykonawczego bez konieczności pisania kodu.

Konfigurowanie instrukcji warunkowych

Działanie warunkowe jest implementowane na serwerach proxy interfejsu API przy użyciu kombinacji warunków. i zmienne. Instrukcja warunkowa jest tworzona za pomocą elementu warunku. Poniżej to pusty warunek:

<Condition></Condition>

Aby utworzyć wyrażenie warunkowe, dodaj operator warunkowy i zmienną, która posłuży do utworzenia następującą strukturę:

<Condition>{variable.name}{operator}{"value"}</Condition>

Obsługiwane operatory warunkowe to = (równa się), != (nie równa się), i > (większe od). Aby zwiększyć czytelność, warunki warunkowe możesz też zapisać jako tekst: equals, notequals, greaterthan.

Podczas pracy ze ścieżkami URI możesz użyć ~/ lub MatchesPath. Dostępne opcje do wyrażenia regularnego JavaRegex możesz też dopasować do operatora ~~.

Warunki są używane do definiowania warunkowych przepływów API serwera proxy interfejsu API do zasobów interfejsu API backendu, co opisano w artykule o tworzeniu przepływów warunkowych do zasobów interfejsu API backendu. Dla: Pełną listę warunków znajdziesz w artykule o warunkach.

Zmienne

Warunki działają, oceniając wartości zmiennych. Zmienna to właściwość transakcji HTTP wykonywanej przez serwer proxy interfejsu API lub właściwość serwera proxy interfejsu API. i samej konfiguracji. Za każdym razem, gdy serwer proxy interfejsu API otrzyma żądanie z aplikacji, Apigee Edge zapełnia pole długa lista zmiennych powiązanych z czasem systemowym, siecią aplikacji informacje, nagłówki HTTP w wiadomościach, konfiguracja serwera proxy API, uruchomienia zasad itd. W ten sposób uzyskasz szczegółowy kontekst, którego możesz używać do konfigurowania instrukcji warunkowych.

Zmienne zawsze używają notacji kropkowanej. Na przykład nagłówki HTTP w wiadomości żądania są dostępne jako zmienne o nazwie request.header.{header_name}. Aby więc ocenić W nagłówku typu treści możesz użyć zmiennej request.header.Content-type. Dla: przykład request.header.Content-type = "application/json" wskazuje, że treść żądania powinno być zapisane w formacie JSON.

Wyobraź sobie, że musisz utworzyć stwierdzenie warunkowe, które spowoduje, że zasada jest egzekwowane tylko wtedy, gdy wiadomość z żądaniem jest metodą GET. Aby utworzyć warunek oceniający czasownik HTTP dla żądania tworzysz instrukcję warunkową poniżej. Zmienna w tym warunku to request.verb Wartość zmiennej wynosi GET. Operatorem jest =

<Condition>request.verb = "GET"</Condition>
Możesz też użyć: 
<Condition>request.verb equals "GET"</Condition>

Edge używa takiego wyrażenia do oceny warunków. W tym przykładzie zwracamy wartość prawda, jeśli Czasownik HTTP powiązany z żądaniem to GET. Jeśli czasownik HTTP powiązany z żądaniem to POST, instrukcja zwraca wartość false (fałsz).

Aby włączyć zachowanie dynamiczne, możesz dołączyć warunki do przepływów, kroków i reguł trasy.

Gdy dołączysz warunek do przepływu, tworzysz „przepływ warunkowy”. Przepływy warunkowe wykonywane tylko wtedy, gdy warunek ma wartość prawda. Możesz dołączyć dowolną liczbę zasad przepływu warunkowego. Przepływ warunkowy umożliwia tworzenie wyspecjalizowanych reguł przetwarzania w przypadku wiadomości z żądaniami lub odpowiedziami, które spełniają określone kryteria.

Aby np. utworzyć przepływ, który jest wykonywany tylko wtedy, gdy czasownik żądania to GET:

<Flows>
  <Flow name="ExecuteForGETs">
  <Condition>request.verb="GET"</Condition>
  </Flow>
</Flows>

Aby utworzyć jeden przepływ dla żądań GET i inny dla POST:

<Flows>
  <Flow name="ExecuteForGETs">
  <Condition>request.verb="GET"</Condition>
  </Flow>
  <Flow name="ExecuteForPOSTs">
  <Condition>request.verb="POST"</Condition>
  </Flow>
</Flows>

Jak widać na przykładzie poniżej, możesz zastosować warunek do samego kroku zasad. poniższy warunek powoduje, że zasada VerifyApiKey jest egzekwowana tylko wtedy, gdy wiadomość żądania jest POST.

<PreFlow name="PreFlow">
    <Request>
        <Step>
            <Condition>request.verb equals "POST"</Condition>
            <Name>VerifyApiKey</Name>
        </Step>
    </Request>
</PreFlow>

Po zdefiniowaniu takich przepływów warunkowych możesz dołączyć do nich zasady, włączając interfejs API serwera proxy do egzekwowania jednego zestawu zasad dla żądań GET i innego dla POST żądań.

Pełne informacje znajdziesz w tych materiałach:

Przykład 1

Poniższy przykład to pojedynczy przepływ warunkowy o nazwie Convert-for-devices. skonfigurowane w procesie odpowiedzi ProxyEndpoint. Dodaj warunek jako element do elementu do którego ma zastosowanie dany warunek. W tym przykładzie warunek jest komponentem przepływu. Dlatego przepływ będzie wykonywany za każdym razem, gdy instrukcja zwróci wartość prawda.

<Flows>
  <Flow name="Convert-for-devices">
  <Condition>(request.header.User-Agent = "Mozilla")</Condition>
    <Response>
      <Step><Name>ConvertToJSON</Name></Step>
    </Response>
  </Flow>
</Flows>

Dla każdego żądania otrzymanego z aplikacji Edge przechowuje wartości wszystkich nagłówków HTTP obecnych jako zmiennych. Jeśli żądanie zawiera nagłówek HTTP o nazwie User-Agent, nagłówek ten oraz jego wartość jest przechowywana jako zmienna o nazwie request.header.User-Agent.

Biorąc pod uwagę powyższą konfigurację ProxyEndpoint, Edge sprawdza wartość request.header.User-Agent, aby sprawdzić, czy warunek przyjmuje wartość true (prawda).

Jeśli warunek zostanie spełniony, oznacza to, że wartość zmiennej request.header.User-Agent równa się Mozilla, a następnie przepływ warunkowy i egzekwowana jest zasada XMLtoJSON o nazwie ConvertToJSON. Jeśli nie, raport Flow nie zostanie wykonany, a odpowiedź XML zostanie zwrócona w postaci niezmodyfikowanej (w formacie XML) do żądania .

Przykład 2

Wykorzystajmy konkretny przykład, w którym musisz przekształcić wiadomość odpowiedzi z pliku XML na JSON, ale tylko na urządzeniach mobilnych. Najpierw utwórz zasadę, która przekształci Odpowiedź w formacie XML z interfejsu Weather API do JSON:

<XMLToJSON name="ConvertToJSON">
  <Options>
  </Options>
  <OutputVariable>response</OutputVariable>
  <Source>response</Source>
</XMLToJSON>

Powyższa konfiguracja zasad informuje serwer proxy interfejsu API, aby pobrać komunikat z odpowiedzią, wykonać konwersji z XML na JSON z ustawieniami domyślnymi, a następnie zapisać wynik w nowej odpowiedzi . Jeśli konwertujesz wiadomość żądanie z XML-a na JSON, ustaw oba parametry te wartości do request).

Chcesz przekonwertować odpowiedzi z XML na JSON, musisz więc skonfigurować do wykonania konwersji. Aby na przykład przekonwertować wszystkie odpowiedzi z formatu XML na JSON, przed ich zwróceniem do aplikacji klienckiej skonfiguruj następującą odpowiedź ProxyEndpoint Flow.

<Flows>
  <Flow name="Convert-for-devices">
    <Response>
      <Step><Name>ConvertToJSON</Name></Step>
    </Response>
  </Flow>
</Flows>

Gdy wywołujesz interfejs API za pomocą żądania standardowego, odpowiedź jest sformatowana w formacie JSON.

Jednak Twoim celem jest konwertowanie raportów pogodowych tylko na format JSON, gdy klient, który wysłał żądanie, jest urządzeniem mobilnym. Aby umożliwić takie dynamiczne zachowanie, musisz dodać instrukcję warunkową do przepływu.

Testowanie warunku warunkowego przepływ

W tym przykładowym żądaniu nagłówek HTTP User-Agent jest ustawiony na Mozilla, przez co wyrażenie warunkowe przyjmuje wartość prawda, a warunek warunkowy proces Convert-for-devices do wykonania.

$ curl -H "User-Agent:Mozilla" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

lub pisać ładnie tam, gdzie dostępny jest Python:

$ curl -H "User-Agent:Mozilla" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282 | python -mjson.tool

Przykładowa odpowiedź:

. . .

"yweather_forecast": [
         {
              "code": "11",
              "date": "12 Dec 2012",
              "day": "Wed",
              "high": "55",
              "low": "36",
              "text": "Showers"
          },
          {
              "code": "32",
              "date": "13 Dec 2012",
              "day": "Thu",
              "high": "56",
              "low": "38",
              "text": "Sunny"
          }
      ]
  }

. . .

Żądanie przesłane bez nagłówka User-Agent lub z inną wartością niż Mozilla zwróci odpowiedź w formacie XML.

$ curl http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

Zwracana jest niezmodyfikowana odpowiedź XML.

Przykładowa odpowiedź:

<yweather:forecast day="Wed" date="12 Dec 2012" low="36" high="55" text="Showers" code="11" /> <yweather:forecast day="Thu" date="13 Dec 2012" low="38" high="56" text="Sunny" code="32" />

Dopasowywanie do wzorca

Z tej sekcji dowiesz się, jak używać dopasowania do wzorca z warunkami w przepływie Apigee.

Operatory

W tej sekcji opisujemy, jak korzystać z operatorów dopasowania do wzorca w warunkach warunkowych wyciągi:

Odpowiada

Spójrzmy na kartę „Dopasowania” lub „~” z operatorem warunkowym. Te dwa operatory to ta sama – wersja angielska „Dopasowania” jest uważana za bardziej czytelną opcję.

Podsumowanie: „Pojedynki” daje dwie możliwości. Dopasuj do lub użyć symbolu wieloznacznego z symbolem „*”. Jak można się spodziewać, symbol wieloznaczny ma wartość zero lub więcej znaków. Zobaczmy, jak to działa.

Poniższy kod XML zawiera warunek kroku. Wykonuje zasadę somePolicy, gdy warunek zwraca wartość prawda. W tym przykładzie testujemy zmienną proxy.pathsuffix, wbudowanej zmiennej Edge, która przechowuje sufiks ścieżki żądania. Pamiętaj, że możesz przetestować wartość dowolnej zmiennej przepływu zawierającej ciąg znaków. Zatem w tym przypadku, jeśli ścieżka podstawowa żądanie przychodzące ma wartość /animals, a żądanie /animals/cat, sufiks ścieżki to ciąg literału „/cat”.

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix Matches "/cat")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

Pytanie: który sufiks ścieżki serwera proxy spowoduje wykonanie reguły somePolicy? Jest tylko jedna możliwość.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/cat

Czy zasada jest wdrażana? Tak, ponieważ sufiks ścieżki serwera proxy pasuje do „/cat” dokładnie. Nie zostanie wykonane, jeśli sufiks to /bat, /dog lub „/” czy cokolwiek innego.

Przyjrzyjmy się teraz instrukcji warunkowej, w której używamy symbolu wieloznacznego. „*”:

<Condition>(proxy.pathsuffix Matches "/*at")</Condition>

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/cat

Czy zasada jest wdrażana? Tak, ponieważ symbol wieloznaczny pasuje do dowolnego znaku, "/cat′′ pasuje.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/bat

Czy zasada jest wdrażana? Tak, ponieważ symbol wieloznaczny pasuje do dowolnego znaku, "/bat" pasuje.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/owl

Czy zasada jest wdrażana? Nie – chociaż symbol wieloznaczny pasuje do „o”, litery „wl” nie są dopasowane.

Przenieśmy teraz symbol wieloznaczny na koniec sufiksu:

<Condition>(proxy.pathsuffix Matches "/cat*")</Condition>

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/cat

Czy zasada jest wdrażana? Tak, ponieważ symbol wieloznaczny pasuje do 0 lub większej liczby znaków.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/bat

Czy zasada jest wdrażana? Nie, „/bat” nie pasuje.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/cat123

Czy zasada jest wdrażana? Tak, symbol wieloznaczny odpowiada zero lub więcej dowolnych znaków, dlatego „123” daje dopasowanie.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/cat/bird/mouse

Czy zasada jest wdrażana? Tak. Symbol wieloznaczny odpowiada zero lub więcej znaków, więc „/bird/mouse” daje dopasowanie. Zastanów się, jak za pomocą tego wyrażenia wciągniesz problem, ponieważ pasuje do wszystkiego po dosłownych znakach!

Pytanie: czy w operatorze Dopasowania rozróżniana jest wielkość liter?

Tak. Załóżmy, że Twój warunek jest taki:

<Condition>(proxy.pathsuffix Matches "/*At")</Condition>

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/cat

Czy zasada jest wdrażana? Nie. Symbol wieloznaczny odpowiada dowolnej literze (w każdym przypadku), ale małe litery „a” nie pasuje do „A”.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/bAt

Czy zasada jest wdrażana? Tak, przypadek się zgadza.

Pytanie: Jak zmienić znaczenie znaków przy użyciu operatora Dopasowania?

Używaj procentu „%” w celu zmiany znaczenia znaków zarezerwowanych. Na przykład:

<Condition>(proxy.pathsuffix Matches "/c%*at")</Condition>

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/cat

Czy zasada jest wdrażana? Nie, operator Dopasowania szuka ciągu literału „c*at”.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/c*at

Pytanie:Czy zasady są wdrażane?

Tak, ta ścieżka pasuje, choć jest nieco nietypowa.

JavaRegex

Jak widać, pole „Dopasowania” jest bardzo przydatne w prostych sytuacjach. Możesz też użyć innego „JavaRegex” lub „~~” . Te dwa operatory to ten sam operator, z wyjątkiem tego, że JavaRegex to które są czytelniejsze. Nazywa się JavaRegex, ponieważ pozwala na wyrażenia regularne do wzorca, a Edge przestrzega tych samych reguł co w klasach w argumencie java.util.regex pakiet w języku Java. Sposób działania operatora JavaRegex znacznie się różni od Pasuje do operatora, dlatego nie należy ich mylić.

Podsumowanie: „JavaRegex” pozwala używać składni wyrażeń regularnych w instrukcjach warunkowych.

Ten kod przedstawia warunek kroku. Wykonuje zasadę somePolicy, jeśli warunek zwraca wartość prawda. W tym przykładzie testujemy wbudowaną zmienną proxy.pathsuffix w Edge, która przechowuje sufiks ścieżki żądania. Jeśli ścieżka podstawowa argumentu żądanie przychodzące ma wartość /animals, a żądanie /animals/cat, sufiks ścieżki to ciąg literału „/cat”.

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix JavaRegex "/cat")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

Pytanie: który sufiks ścieżki serwera proxy spowoduje wykonanie reguły somePolicy? Tak jak w przypadku operatora Dopasowania jest w tym przypadku tylko jedna możliwość.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/cat

Czy zasada jest wdrażana? Tak, ponieważ sufiks ścieżki serwera proxy pasuje do „/cat” dokładnie. Nie uruchomi się, jeśli sufiks to /bat, /dog lub cokolwiek .

Utwórz wyrażenie regularne zawierające symbol „*” kwantyfikator. Ten kwantyfikator odpowiada zeru lub poprzedniego znaku.

<Condition>(proxy.pathsuffix JavaRegex "/c*t")</Condition>

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/cat

Czy zasada jest wdrażana? Nie! Symbol „*” kwantyfikator pasuje do zero lub większej liczby poprzedni znak, który jest „c”.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/ccccct

Czy zasada jest wdrażana? Tak, ponieważ symbol wieloznaczny pasuje do 0 lub większej liczby poprzednich znaku.

Następnie używamy kolumny „?” kwantyfikator, który pasuje do poprzedniego znaku raz lub nie .

<Condition>(proxy.pathsuffix JavaRegex "/ca?t")</Condition>

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/cat

Czy zasada jest wdrażana? Tak. „?” kwantyfikator pasuje do zero lub jednego wystąpienia poprzedni znak, który jest „a”.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/ct

Czy zasada jest wdrażana? Tak. „?” kwantyfikator pasuje do jednego lub brak poprzedniego znaku. W tym przypadku nie ma „a” tak więc makro zwraca wartość prawda.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/caat

Czy zasada jest wdrażana? Nie. Symbol „?” kwantyfikator pasuje do jednego z poprzednich który jest znakiem „a”.

Następnie używamy kolumny „[abc]” lub „grupowanie” stylu wyrażenia regularnego. Pasuje do znaki „a” lub „b” lub „c”.

<Condition>(proxy.pathsuffix JavaRegex "/[cbr]at")</Condition>

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/cat

Czy zasada jest wdrażana? Tak. Używamy tu wyrażeń regularnych, a „[cbr]” pasuje do „c”, „b” lub „r”. Te połączenia są również dopasowane:

GET http://artomatic-test.apigee.net/matchtest/bat

GET http://artomatic-test.apigee.net/matchtest/rat

Ale to nie pasuje:

GET http://artomatic-test.apigee.net/matchtest/mat

Pytanie: czy w operatorze JavaRegex wielkość liter ma znaczenie?

Tak. Załóżmy, że Twój warunek jest taki:

<Condition>(proxy.pathsuffix JavaRegex "/ca?t")</Condition>

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/cat

Czy zasada jest wdrażana? Tak. Wyrażenie regularne odpowiada zero lub jednemu z poprzedzających znaków, które jest „a”.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/cAt

Pytanie: Czy zasada jest wdrażana?

Nie, ponieważ wielka litera „A” nie pasuje do małych liter.

MatchesPath

Operator MatchesPath możesz też określić w ten sposób: „~/”. Wygląda trochę jak Matches (~) oraz operatory JavaRegex (~~). Ścieżka MatchPath jest jednak zupełnie inna.

Pamiętaj tylko, że ten operator traktuje ścieżkę jako serię części. Dlatego, jeśli ścieżka jest: /animals/cats/wild, możesz wyobrazić sobie, że ścieżka składa się z części, „/animals”, „/cats” i „/wild”.

Operator MatchesPath pozwala używać dwóch znaków wieloznacznych: jednej gwiazdki (*) i podwójna gwiazdka (**). Pojedyncza gwiazdka pasuje do jednego elementu ścieżki. Podwójna gwiazdka pasuje do: jeden lub wiele elementów ścieżki.

Przeanalizujmy poniższy przykład. W tym przykładzie testujemy zmienną proxy.pathsuffix, zmienną wbudowaną w Edge, która przechowuje sufiks ścieżki żądania. Pamiętaj jednak, że możesz testować wartość dowolnej zmiennej przepływu, która zawiera ciąg znaków.

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix MatchesPath "/animals/*")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

Pytanie: który sufiks ścieżki serwera proxy spowoduje wykonanie reguły somePolicy?

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/animals

Pytanie: Czy zasada jest wdrażana?

Nie, ponieważ warunek wymaga kolejnego elementu ścieżki po „/animals”, zgodnie z wartością podaną przez „/*”.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/animals

Czy zasada jest wdrażana? Tak, ścieżka ma inny element ścieżki (część za nim „/animals/”), ale jest on pusty.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/animals/cats

Czy zasada jest wdrażana? Tak, ponieważ ścieżka wyraźnie zawiera element („/cats”) występujący po „/animals”

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/animals/cats/wild

Pytanie: Czy zasada jest wdrażana?

Nie, ponieważ pojedyncza gwiazdka pasuje tylko do jednego elementu ścieżki, ten interfejs API zawiera więcej niż 1 element po „/animals”.

Teraz użyjmy podwójnej gwiazdki:

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix MatchesPath "/animals/**")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

Pytanie: który sufiks ścieżki serwera proxy spowoduje wykonanie reguły somePolicy?

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/animals

Czy zasada jest wdrażana? Nie, ponieważ warunek wymaga co najmniej jednego kolejnego elementu ścieżki określona przez „/**”.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/animals

Czy zasady są wdrażane?

Tak, ścieżka ma inny element ścieżki (część za nim „/animals/”), ale jest on pusty.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/animals/cats

Czy zasady są wdrażane?

Tak, ponieważ ścieżka zawiera co najmniej jeden element występujący za nim „/animals”

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/animals/cats/wild

Czy zasady są wdrażane?

Tak, ponieważ ścieżka zawiera więcej niż jeden element, który występuje za nim „/animals”

Łączenie gwiazdek

Możesz użyć kombinacji gwiazdek pojedynczej (*) i podwójnej (**) w celu dalszego doprecyzowania dopasowania ścieżki.

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix MatchesPath "/animals/*/wild/**")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

Wywołanie interfejsu API:

Wszystkie te wywołania interfejsu API zapewnią dopasowanie:

GET http://artomatic-test.apigee.net/matchtest/animals/cats/wild/,

oraz

GET http://artomatic-test.apigee.net/matchtest/animals/dogs/wild/austrailian,

oraz

GET http://artomatic-test.apigee.net/matchtest/animals/birds/wild/american/finches

Zasoby interfejsu API

Usługi REST to zbiory zasobów interfejsów API. Zasób interfejsu API jest ścieżką identyfikatora URI fragment określający jednostkę, do której programiści mogą uzyskać dostęp za pomocą wywołania interfejsu API. Przykład: jeśli Twoja usługa dostarcza prognozy pogody i prognozy pogody, usługa backendu może określić dwa zasoby API:

  • http://mygreatweatherforecast.com/reports
  • http://mygreatweatherforecast.com/forecasts

Tworząc serwer proxy interfejsu API (jak pokazano w sekcji Tworzenie pierwszego serwera proxy API), tworzysz przynajmniej alias podstawowy URL mapowany na usługę backendu. Na przykład:

Podstawowy adres URL backendu Nowy/odpowiednik URL serwera proxy API
http://mygreatweatherforecast.com http://{your_org}-{environment}.apigee.net/mygreatweatherforecast

Na tym etapie możesz wykonywać wywołania interfejsu API w backendzie przy użyciu dowolnego podstawowego adresu URL. Jeśli jednak używasz funkcji adresu URL serwera proxy interfejsu API, wszystko zaczyna się robić interesujące.

Oprócz statystyk interfejsu API, które Edge zaczyna zbierać podczas używania serwera proxy API, serwery proxy pozwalają też definiować przepływy warunkowe mapowane na zasoby w backendzie. W skrócie: „Jeśli wywołanie GET jest przekazywane do zasobu /reports, Edge powinien coś zrobić”.

Na ilustracji poniżej przedstawiono różnicę w działaniu dwóch adresów URL, które uzyskują dostęp do z tego samego backendu. Jeden to adres URL zasobu bez serwera proxy, drugi to serwer proxy interfejsu Edge API z z przepływem warunkowym do tego samego zasobu backendu. Przepływy warunkowe zostaną opisane bardziej szczegółowo poniżej.

Jak serwery proxy interfejsów API mapują się na konkretne zasoby backendu

Gdy adres URL serwera proxy interfejsu API jest zmapowany na podstawowy adres URL usługi backendu (podczas tworzenia proxy), możesz dodać przepływy warunkowe do określonych zasobów, takich jak /reports i /forecasts zasobów wspomnianych wcześniej.

Załóżmy, że chcesz, by Edge „zrobił coś” przy połączeniach przychodzących na /reports lub /forecasts zasobu. W tym momencie nie informujesz Edge co zrobić. Po prostu nasłuchuj połączeń do tych zasobów. Zrób to warunki. Na serwerze proxy interfejsu Edge API możesz tworzyć przepływy warunkowe dla /reports i /forecasts. Do celów koncepcyjnych poniższy interfejs API kod XML serwera proxy pokazuje, jak mogą wyglądać te warunki.

<Flows>
    <Flow name="reports">
        <Description/>
        <Request/>
        <Response/>
        <Condition>(proxy.pathsuffix MatchesPath "/reports") and (request.verb = "GET")</Condition>
    </Flow>
    <Flow name="forecasts">
        <Description/>
        <Request/>
        <Response/>
        <Condition>(proxy.pathsuffix MatchesPath "/forecasts") and (request.verb = "GET")</Condition>
    </Flow>
</Flows>

Warunki te mają postać „Gdy przychodzi żądanie GET z /reports i /forecasts w adresie URL, Edge wykona to, co poprosi Cię (deweloper interfejsu API) przez zasady dołączane do tych procesów.

Oto przykład, który informuje Edge o tym, co ma zrobić, gdy zostanie spełniony warunek. W poniższym interfejsie API XML serwera proxy, gdy żądanie GET jest wysyłane do https://yourorg-test.apigee.net/mygreatweatherforecast/reports, Edge jest wykonywany „XML-to-JSON-1” zasady w odpowiedzi.

<Flows>
    <Flow name="reports">
        <Description/>
        <Request/>
        <Response>
            <Step>
                <Name>XML-to-JSON-1</Name>
            </Step>
        </Response>
        <Condition>(proxy.pathsuffix MatchesPath "/reports") and (request.verb = "GET")</Condition>
</Flow>

Oprócz tych opcjonalnych przepływów warunkowych każdy serwer proxy interfejsu API ma również dwa domyślne przepływy: <PreFlow> wykonany przed przepływami warunkowymi, Metoda <PostFlow> została wykonana po przepływach warunkowych. Przydają się one: podczas wykonywania zasad w przypadku dowolnego wywołania serwera proxy interfejsu API. Jeśli chcesz na przykład klucza interfejsu API aplikacji musisz weryfikować przy każdym wywołaniu niezależnie od używanego zasobu backendu może umieścić zasadę weryfikacji klucza interfejsu API w <PreFlow>. Więcej informacji o przepływach: Konfigurowanie przepływów.

Tworzenie przepływów warunkowych do zasobów backendu

Definiowanie przepływów warunkowych do zasobów backendu na serwerze proxy interfejsu API jest całkowicie opcjonalne. Takie procesy warunkowe dają jednak możliwość szczegółowego zarządzania i monitorowania.

Dzięki niemu:

  • Stosuj zarządzanie w sposób odzwierciedlający semantykę modelu interfejsu API
  • Stosowanie zasad i zachowań skryptów do poszczególnych ścieżek zasobów (identyfikatorów URI)
  • Zbieranie szczegółowych danych na potrzeby usług Analytics

Na przykład wyobraź sobie, że musisz zastosować różne typy logiki do backendu /developers do zasobów /apps.

Aby to zrobić, dodaj 2 przepływy warunkowe na serwerze proxy API: /developers oraz /apps

W widoku Programowanie w panelu Nawigator edytora serwera proxy interfejsów API kliknij ikonę +. obok wartości domyślnej w punktach końcowych serwera proxy.

W sekcji „Nowy przepływ warunkowy” wpisz następujące konfiguracje kluczy:

  • Nazwa przepływu: Deweloperzy
  • Typ warunku: Ścieżka
  • Ścieżka: /developers

Warunek zostanie aktywowany (i zasady zostaną wykonane), jeśli wywołanie zostanie wysłane do serwera proxy z /developers na końcu identyfikatora URI.

Teraz dodaj przepływ warunkowy dla /apps i załóżmy, że chcesz, aby warunek był wywoływany identyfikator URI i czasownik POST w żądaniu. Konfiguracja obejmuje ustawienie :

  • Flow Name (Nazwa przepływu): Aplikacje
  • Typ warunku: Ścieżka i Czasownik
  • Ścieżka: /apps
  • Czasownik: POST

Warunek zostanie aktywowany (i zasady zostaną wykonane), jeśli wywołanie zostanie wysłane do serwera proxy z /apps na końcu identyfikatora URI i z czasownikiem POST.

W panelu Nawigator zobaczysz nowe przepływy dla aplikacji i Deweloperzy.

Wybierz jeden z przepływów, aby wyświetlić konfigurację przepływu warunkowego w edytorze serwera proxy interfejsu API widok kodu:

<Flow name="Apps">
    <Description>Developer apps registered in Developer Services</Description>
    <Request/>
    <Response/>
    <Condition>(proxy.pathsuffix MatchesPath "/apps") and (request.verb = "POST")</Condition>
</Flow>

Jak widać, zasoby interfejsu API są po prostu przepływami warunkowymi, które oceniają ścieżkę URI ścieżki dostępu żądania przychodzącego. (Zmienna proxy.pathsuffix identyfikuje identyfikator URI żądania, które następuje po ścieżki BasePath skonfigurowanej w konfiguracji ProxyEndpoint).

Każdy zdefiniowany zasób API jest zaimplementowany przez przepływ warunkowy na serwerze proxy API. (Zobacz Konfigurowanie przepływów).

Po wdrożeniu serwera proxy interfejsu API w środowisku testowym to żądanie:

http://{org_name}-test.apigee.net/{proxy_path}/apps

spowoduje, że warunek zostanie oceniony jako prawda, a ten przepływ, a także wszystkie powiązane będą wdrażane.

W poniższym przykładowym warunku użyto wyrażenia regularnego Javy do rozpoznawania wywołań funkcji /apps zasób z ukośnikiem na końcu lub bez niego (/apps lub /apps/**):

<Condition>(proxy.pathsuffix JavaRegex "/apps(/?)") and (request.verb = "POST")</Condition>

Więcej informacji o tym typie warunku znajdziesz w artykule Jak dopasować niezależnie ... w Społeczności Apigee.

Modelowanie hierarchicznych identyfikatorów URI

W niektórych przypadkach będziesz mieć zasoby hierarchicznego interfejsu API. Na przykład Usługi dla deweloperów Interfejs API udostępnia metodę wyświetlania listy wszystkich aplikacji należących do dewelopera. Ścieżka identyfikatora URI to:

/developers/{developer_email}/apps

Mogą istnieć zasoby, w których dla każdego elementu w kolekcji generowany jest unikalny identyfikator, który jest czasami oznaczany w taki sposób:

/genus/:id/species

Ta ścieżka dotyczy w równym stopniu tych dwóch identyfikatorów URI:

/genus/18904/species
/genus/17908/species

Aby przedstawić tę strukturę w zasobie interfejsu API, możesz użyć symboli wieloznacznych. Na przykład:

/developers/*/apps

/developers/*example.com/apps

/genus/*/species

poprawnie rozpozna te hierarchiczne identyfikatory URI jako zasoby interfejsu API.

W niektórych przypadkach zwłaszcza w przypadku bardzo hierarchicznych interfejsów API, najlepiej będzie po prostu rozwiązywać wszystkie problemy, które są danego fragmentu identyfikatora URI. Aby to zrobić, w definicji zasobu użyj symbolu wieloznacznego z podwójną gwiazdką. Dla: możesz na przykład zdefiniować następujący zasób interfejsu API: 
/developers/**

Ten zasób interfejsu API rozpozna następujące ścieżki identyfikatora URI:

/developers/{developer_email}/apps
/developers/{developer_email}/keys
/developers/{developer_email}/apps/{app_id}/keys

Tak wyglądałby warunek warunkowego przepływu w definicji serwera proxy interfejsu API:

<Condition>(proxy.pathsuffix MatchesPath "/developers/**") and (request.verb = "POST")</Condition>

Więcej przykładów

Warunek dołączony do reguły routingu

<RouteRule name="default">
 <!--this routing executes if the header indicates that this is an XML call. If true, the call is routed to the endpoint XMLTargetEndpoint-->
  <Condition>request.header.content-type = "text/xml"</Condition>
  <TargetEndpoint>XmlTargetEndpoint</TargetEndpoint>
</RouteRule>

Warunek dołączony do zasady

<Step>
<!--the policy MaintenancePolicy only executes if the response status code is exactly 503-->
  <Condition>response.status.code = 503</Condition>
  <Name>MaintenancePolicy</Name>
</Step>

Przepływ warunkowy

<!-- this entire flow is executed only if the request verb is a GET-->
<Flow name="GetRequests">
  <Condition>request.verb="GET"</Condition>
  <Request>
    <Step>
<!-- this policy only executes if request path includes a term like statues-->
<Condition>request.path ~ "/statuses/**"</Condition>
      <Name>StatusesRequestPolicy</Name>
    </Step>
  </Request>
  <Response>
    <Step>
<!-- this condition has multiple expressions. The policy executes if the response code status is exactly 503 or 400-->
<Condition>(response.status.code = 503) or (response.status.code = 400)</Condition>
      <Name>MaintenancePolicy</Name>
    </Step>
  </Response>
</Flow>

Przykładowe operatory w warunkach

Oto kilka przykładów operatorów używanych do tworzenia warunków:

  • request.header.content-type = "text/xml"
  • request.header.content-length < 4096 && request.verb = "PUT"
  • response.status.code = 404 || response.status.code = 500
  • request.uri MatchesPath "/*/statuses/**"
  • request.queryparam.q0 NotEquals 10

Praktyczny przykład: Ignoruj znak „/” w koniec ścieżki

Deweloperzy brzegowi często chcą obsługiwać oba te sufiksy ścieżek: „/cat” oraz „/cat/”. Dzieje się tak, ponieważ niektórzy użytkownicy lub klienci mogą wywoływać interfejs API z dodatkowym na końcu ścieżki. Musisz być w stanie obsłużyć to w argumencie wyciągów. Dokładny przypadek użycia: zostało omówione w społeczności Apigee.

Możesz to zrobić bez użycia wyrażenia regularnego w ten sposób:

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>((proxy.pathsuffix = "/cat") OR (proxy.pathsuffix = "/cat/")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

To dobra opcja. Jest zrozumiałe i czytelne.

To samo możesz zrobić w przypadku wyrażenia regularnego, ale w ten sposób. Nawiasy są używane do grupowania wyrażenia regularnego, ale nie są one wymagane.

<Condition>(proxy.pathsuffix JavaRegex "/cat(/?)"</Condition>

Wywołania interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/cat
or ,
GET http://artomatic-test.apigee.net/matchtest/cat/

Czy zasada jest wdrażana? Tak. Zwróć uwagę, że w wyrażeniu regularnym parametr „?” znak oznacza: dopasowanie zero lub jednego z poprzedzających znaków. Obie funkcje „/cat” i „/cat/” dopasowania.

Wywołanie interfejsu API:

GET http://artomatic-test.apigee.net/matchtest/cat/spotted

Czy zasada jest wdrażana? Nie. Wyrażenie regularne odpowiada zero lub tylko jednemu wystąpieniu poprzedzający ten znak i nic nie jest dozwolone.

Dopasowywanie dowolnych ciągów znaków za pomocą JavaRegex

We wszystkich przykładach w tym temacie pokazujemy, jak dopasować jedną z wbudowanych zmiennych przepływu: proxy.pathsuffix. Warto wiedzieć, że dopasowywanie do wzorca można zastosować w przypadku dowolnego ciągu niezależnie od tego, czy jest to wbudowana zmienna przepływu, np. proxy.pathsuffix.

Jeśli na przykład warunek, który testuje dowolny ciąg znaków, w ładunku backendu lub ciągu znaków zwróconego podczas wyszukiwania serwera uwierzytelniania, możesz użyć funkcji i operatorów wyszukiwania. Jeśli używasz języka JavaRegex, wyrażenie regularne zostanie porównane względem całego ciągu tematu. Jeśli temat to „abc” a wyrażenie regularne to „[a-z]”, brak dopasowań, ponieważ „[a-z]” pasuje dokładnie jeden znak alfa. wyrażenie „[a-z]+” oraz „[a-z]*” i „[a-z]{3}.

Spójrzmy na konkretny przykład. Załóżmy, że serwer uwierzytelniania zwraca listę ról jako ciąg oddzielony przecinkami: „redaktor, autor, gość”.

Aby przetestować obecność roli edytującego, ta konstrukcja nie zadziała, ponieważ „Edytujący” to tylko część całego ciągu.

<Condition>returned_roles ~~ "editor"</Condition>

Taka konstrukcja będzie jednak działać:

<Condition>returned_roles ~~ ".*\beditor\b.*")</Condition>

Działa, ponieważ uwzględnia podziały słów i inne części ciągu znaków ze znakiem .* przedrostkiem i sufiksem.

W tym przykładzie możesz też przetestować działanie funkcji „editor” z operatorem Dopasowania:

<Condition>returned_roles ~~ "*editor*")</Condition>

Jeśli jednak potrzebujesz większej precyzji, JavaRegex jest często lepszym rozwiązaniem.

Zmiana znaczenia podwójnych cudzysłowów w wyrażeniach JavaRegex

Składnia warunku wymaga zastosowania wyrażenia JavaRegex w cudzysłowach podwójnych. dlatego, jeśli masz Wyrażenie regularne zawiera cudzysłowy podwójne, ale musisz użyć innego sposobu ich dopasowania. Odpowiedź brzmi: Unicode. Załóżmy na przykład, że przekazujesz nagłówek zawierający podwójny cudzysłów, jak w poniższym przykładzie: 
 -H 'content-type:multipart/related; type="application/xop+xml"'
 Jeśli spróbujesz dopasować ten nagłówek w warunku wyrażenia regularnego, pojawi się błąd nieprawidłowego warunku, ponieważ wyrażenie zawiera podwójny cudzysłów: 
request.header.Content-Type ~~ "(multipart\/related)(; *type="application\/xop\+xml\")"
 Rozwiązaniem jest zastąpienie cudzysłowów podwójnych opartych na ASCII ich odpowiednikiem w systemie Unicode \u0022. Przykład: następujące wyrażenie jest prawidłowe i zwraca oczekiwany wynik: 
request.header.Content-Type ~~ "(multipart\/related)(; *type=\u0022application\/xop\+xml\u0022)"