Akış değişkenli koşullar

Apigee Edge belgelerini görüntülüyorsunuz.
. Git: Apigee X belgeleri. bilgi

Koşullu ifadeler, tüm programlama dillerinde ortak bir kontrol yapısıdır. Beğen API proxy yapılandırması Akışlar için koşullu ifadeleri, Politikalar, Adımlar ve RouteRules. Koşullu ifadeler tanımlayarak dinamik davranışları tanımlarsınız API'niz için. Bu dinamik davranış, XML'i yalnızca mobil cihazlar için JSON'a dönüştürme veya istek mesajının içerik türüne ya da HTTP fiili'ne göre arka uç URL'sine yönlendirme gibi işlemler yapmanıza olanak tanır.

Bu konu, aşağıdaki adreste API yönetimi özelliklerini dinamik olarak uygulamak için koşulların nasıl kullanılacağını gösterir: hiçbir kod yazmadan çalışmanızı sağlar.

Video

Akış değişkenleri ve koşulları hakkında daha fazla bilgi edinmek için aşağıdaki videoyu izleyin:

Koşullu ifadeleri yapılandırma

Koşullu davranış, API proxy'lerinde koşullar ve değişkenler kullanılarak uygulanır. Koşullu ifade, Condition öğesi kullanılarak oluşturulur. Aşağıdaki koşul boştur:

<Condition></Condition>

Koşullu ifade oluşturmak için bir koşullu operatör ve bir değişken ekleyerek şu yapıda:

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

Desteklenen koşullu operatörler şunlardır: = (eşittir), != (eşit değildir), ve > (büyüktür). Koşullu ifadeleri okunabilirlik için metin olarak da yazabilirsiniz: equals, notequals, greaterthan.

URI yollarıyla çalışırken ~/ veya MatchesPath kullanabilirsiniz. JavaRegex normal ifadelerini ~~ operatörüyle de eşleştirebilirsiniz.

Koşullar, aşağıda açıklandığı gibi arka uç API kaynaklarına API proxy'si koşullu akışlarını tanımlamak için kullanılır Arka uç API kaynaklarına koşullu akışlar oluşturma başlıklı makaleyi inceleyin. Koşullu ifadelerin tam listesi için Koşullar referansı başlıklı makaleyi inceleyin.

Değişkenler

Koşullar, değişkenlerin değerlerini değerlendirerek çalışır. Değişken, API proxy'si tarafından yürütülen bir HTTP işleminin veya API proxy yapılandırmasının bir özelliğidir. Bir API proxy'si bir uygulamadan istek aldığında Apigee Edge, sistem zamanı, uygulamanın ağ bilgileri, mesajlardaki HTTP üst bilgileri, API proxy yapılandırması, politika yürütmeleri vb. gibi öğelerle ilişkili uzun bir değişken listesi doldurur. Bu, koşullu ifadeleri ayarlamak için kullanabileceğiniz zengin bir bağlam oluşturur.

Değişkenler her zaman noktalı gösterim kullanır. Örneğin, istek mesajındaki HTTP üstbilgileri request.header.{header_name} adlı değişkenler şeklinde kullanılabilir. Bu nedenle, İçerik türü üstbilgisi için request.header.Content-type değişkenini kullanabilirsiniz. Örneğin, örnek request.header.Content-type = "application/json", içeriğin istek türü JSON olmalıdır.

Bir politikanın politikaya uygun olmasını sağlayacak yalnızca istek mesajı GET olduğunda zorunlu kılınır. HTTP fiilini değerlendiren bir koşul oluşturmak için aşağıdaki koşullu ifadeyi oluşturursunuz. Bu koşuldaki değişken request.verb Değişkenin değeri GET. Operatör: =.

<Condition>request.verb = "GET"</Condition>

Aşağıdakileri de kullanabilirsiniz:

<Condition>request.verb equals "GET"</Condition>

Edge, koşulları değerlendirmek için bu tür bir ifade kullanır. Yukarıdaki örnek, İstekle ilişkili HTTP fiili GET'dir. İstekle ilişkili HTTP fiili POST ise ifade yanlış olarak değerlendirilir.

Dinamik davranışı etkinleştirmek için akışlara, adımlara ve RouteRules'a koşullar ekleyebilirsiniz.

Bir akışa koşul eklediğinizde "koşullu akış" oluşturursunuz. Koşullu akışlar yalnızca koşul doğru olarak değerlendirildiğinde yürütülür. Koşullu bir akışa istediğiniz sayıda politika ekleyebilirsiniz. Koşullu akış, belirli ölçütleri karşılayan istek veya yanıt iletileri için son derece özel işleme kuralları oluşturmanıza olanak tanır.

Örneğin, yalnızca istek fiili GET olduğunda yürütülecek bir akış oluşturmak için:

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

GET'ler için bir, POST'lar için başka bir akış oluşturmak üzere:

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

Aşağıdaki örnekte gösterildiği gibi, koşulu Politika Adımının kendisine uygulayabilirsiniz. Aşağıdaki koşul, VerifyApiKey politikasının yalnızca istek mesajı bir POST ise uygulanmasına neden olur.

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

Bu tür koşullu akışları tanımladıktan sonra, API proxy'sinin GET istekleri için bir politika grubunu, POST istekleri için de başka bir politika grubunu uygulamasını sağlayarak politikaları bu akışlara ekleyebilirsiniz.

Kapsamlı referans bilgileri için aşağıdaki kaynaklara göz atın:

• Akış değişkenleri referansı
• Koşul referansı

1. Örnek

Aşağıdaki örnekte, ProxyEndpoint yanıt akışında yapılandırılmış Convert-for-devices adlı tek bir koşullu akış gösterilmektedir. Koşulu, geçerli olduğu öğeye öğe olarak ekleyin. Bu örnekte koşul, akışın bir bileşenidir. Bu nedenle, ifade doğru olarak değerlendirildiğinde akış yürütülür.

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

Bir uygulamadan alınan her istek için Edge, mevcut tüm HTTP üstbilgilerinin değerlerini değişkenlerine karşılık gelir. İstek User-Agent adlı bir HTTP başlığı içeriyorsa bu başlık ve değeri request.header.User-Agent adlı bir değişkende depolanır.

Yukarıdaki ProxyEndpoint yapılandırması göz önüne alındığında Edge, koşulun doğru olup olmadığını görmek için request.header.User-Agent değişkeninin değerini kontrol eder.

Koşul doğru olarak değerlendirilirse, yani değişkenin değeri request.header.User-Agent eşittir Mozilla, ardından koşullu Akış yürütülür ve ConvertToJSON adlı XMLtoJSON politikası uygulanır. Aksi halde, Akış yürütülmez ve XML yanıtı, istekte bulunan kullanıcıya değiştirilmemiş (XML biçiminde) döndürülür uygulamasını indirin.

2. Örnek

Yanıt mesajını XML'den JSON (yalnızca mobil cihazlar için). İlk olarak, Weather API'den JSON'ye XML biçimli yanıt:

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

Yukarıdaki politika yapılandırması, API proxy'sine yanıt mesajını almasını, ardından bir XML'den JSON'ye dönüştürmeyi deneyin ve daha sonra, sonucu yeni yanıta yazın mesajını alırsınız. (Bir istek mesajını XML'den JSON'a dönüştürüyorsanız bu iki değeri de request olarak ayarlamanız yeterlidir.)

Yanıtları XML'den JSON'ye dönüştürmek istediğiniz için, yanıt Akışı'nı tıklayın. Örneğin, istemci uygulamasına döndürülmeden önce tüm yanıtları XML'den JSON'a dönüştürmek için aşağıdaki ProxyEndpoint yanıt akışını yapılandırın.

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

API'yi standart isteği kullanarak çağırdığınızda yanıt JSON biçiminde biçimlendirilir.

Ancak amacınız, yalnızca istek gönderen istemci mobil cihaz olduğunda hava durumu raporlarını JSON'a dönüştürmektir. Bu tür dinamik davranışı etkinleştirmek için akışa koşullu bir ifade eklemeniz gerekir.

Koşulu test etme akış

Bu örnek istekte HTTP User-Agent başlığı Mozilla (koşullu ifadenin doğru ve koşullu Convert-for-devices akışını uygulayın.

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

veya Python'un kullanılabildiği yerlerde güzel bir şekilde yazdırmak için:

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

Örnek Yanıt:

. . .

"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"
          }
      ]
  }

. . .

User-Agent başlığı olmadan veya şundan farklı bir değerle gönderilmiş bir istek Mozilla biçimi, XML biçimli bir yanıt oluşturur.

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

Değiştirilmemiş XML yanıtı döndürülür.

Örnek Yanıt:

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

Desen eşleştirme

Bu bölümde, Apigee akışlarında kalıp eşleştirmenin koşullarla nasıl kullanılacağı açıklanmaktadır.

Daha fazla bilgi

Operatörler

Bu bölümde, koşullu ifadelerde aşağıdaki kalıp eşleştirme operatörlerinin nasıl kullanılacağı açıklanmaktadır:

• Eşleşme operatörü: Basit kalıp eşleştirme
• JavaRegex operatörü: Eşleştirme üzerinde daha hassas kontrol
• MatchesPath operatörü: Yol parçası eşleştirme

Eşleşmeler

"Eşleşmeler"e bakalım. veya "~" koşullu operatöre öncelik verin. Bu iki operatör İngilizce sürüm olan "Eşleşmeler", daha okunaklı bir seçenek olarak kabul edilir.

Özet: "Eşleşir" operatörü size iki seçenek sunar. İkisinden biri dizesinin olduğu gibi veya "*" ile joker karakter eşleştirmesi yapılmalıdır. Tahmin edebileceğiniz gibi, joker karakter sıfır ile eşleşir veya daha fazla karakter kullanabilirsiniz. Şimdi, bunun işleyiş şekline göz atalım.

Aşağıdaki XML'de bir Adım koşulu gösterilmektedir. Koşul şu olduğunda AnyPolicy politikasını yürütür doğru olarak değerlendirilir. Bu örnekte, bir proxy.pathsuffix olan <br> Edge'de isteğin yol son ekini depolayan yerleşik değişkendir. Ancak dize içeren herhangi bir akış değişkeninin değerini test edebileceğinizi unutmayın. Bu durumda, gelen isteğinin temel yolu /animals ve istek /animals/cat ise yol soneki "/cat" değişmez dizesi olur.

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

Soru: Hangi proxy yolu soneki SomePolicy'nin yürütülmesine neden olur? Evet, yalnızca tek bir olasılıktır.

API çağrısı:

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

Politika geçerli mi? Evet, çünkü proxy yolu son eki "/cat" ile eşleşir tam olarak bunu sağlar. Son ek /bat veya /dog ya da "/" veya başka bir şeyse yürütülmez.

Şimdi, joker karakter karakterini kullandığımız bu koşullu ifadeyi ele alalım "*":

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

API çağrısı:

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

Politika geçerli mi? Evet, çünkü joker karakter herhangi bir karakterle eşleşir ve "/cat inç eşleşmedir.

API Çağrısı:

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

Politika uygulanıyor mu? Evet, joker karakter herhangi bir karakterle eşleştiği için "/bat" eşleşmedir.

API Çağrısı:

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

Politika geçerli mi? Elbette değil. Joker karakter "o" ile eşleşse de "wl" harfleri eşleşmez.

Şimdi, joker karakteri son ekin sonuna taşıyalım:

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

API çağrısı:

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

Politika geçerli mi? Evet, çünkü joker karakter herhangi bir karakterin sıfır veya daha çok tekrarıyla eşleşir.

API Çağrısı:

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

Politika geçerli mi? Hayır, "/bat" eşleşmez.

API çağrısı:

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

Politika uygulanıyor mu? Evet, joker karakter herhangi bir karakterin sıfır veya daha çok tekrarıyla eşleşir. "123" bir eşleşme getirir.

API çağrısı:

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

Politika geçerli mi? Evet, çünkü joker karakter herhangi bir karakterin sıfır veya daha fazlasıyla eşleşir. Bu nedenle "/bird/mouse" eşleşme oluşturur. Bunun gibi bir ifadenin çünkü harften sonraki her şeyle eşleşiyor!

Soru: Eşleşmeler operatörü büyük/küçük harfe duyarlı mıdır?

Evet. Aşağıdaki gibi bir koşulunuz olduğunu varsayalım:

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

API çağrısı:

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

Politika uygulanıyor mu? Hayır, joker karakter herhangi bir harfle (büyük/küçük harfe bakılmaksızın) eşleşir, ancak küçük harfle "a" "A" ile eşleşmez.

API çağrısı:

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

Politika geçerli mi? Evet, destek kaydı eşleşiyor.

Soru: Eşleşmeler operatörüyle karakterlerin çıkışını nasıl yapabilirim?

"%" yüzdesini kullanın karakterini kullanın. Örneğin:

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

API çağrısı:

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

Politika uygulanıyor mu? Hayır, Eşle operatörü "c*at" değişmez dizesini arar.

API çağrısı:

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

Soru: Politika uygulanıyor mu?

Evet, biraz alışılmadık olsa da bu yol eşleşiyor.

JavaRegex

Gördüğünüz gibi, "Eşleşmeler" operatörü kullanmak basit durumlar için idealdir. Ancak başka bir operatörü, "JavaRegex" veya "~~" operatörümüzü kullanabilirsiniz. Bu ikisi aynı operatördür, ancak JavaRegex daha okunabilir olarak kabul edilir. Normal ifade kalıp eşleştirmesine izin verdiği ve Edge'in Java dilinde java.util.regex paketindeki sınıflarla aynı kurallara uyduğu için JavaRegex olarak adlandırılır. JavaRegex operatörünün çalışma şekli Operatör eşleşiyor, bu nedenle ikisini karıştırmamak önemlidir.

Özet: "JavaRegex" operatörü, koşullu ifadelerde normal ifade söz dizimini kullanmanıza olanak tanır.

Aşağıdaki kodda bir Adım koşulu gösterilmektedir. Koşul doğru olarak değerlendirilirse SomePolicy politikasını yürütür. Bu örnekte, yerleşik bir öğe olan proxy.pathsuffix değişkenini test ediyoruz değişkeni kullanabilirsiniz. Gelen isteğinin temel yolu /animals ve istek /animals/cat ise yol soneki "/cat" değişmez dizesini ifade eder.

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

.

Soru: Hangi proxy yolu soneki, SomePolicy'nin yürütülmesine neden olur? Aynı işlecini eşleştirmek için bu durumda tek bir olasılık vardır.

API çağrısı:

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

Politika uygulanıyor mu? Evet, çünkü proxy yolu son eki "/cat" ile tam olarak eşleşiyor. Son ek /bat veya /dog ya da başka bir şeyse yürütülmez.

Şimdi "*" kullanarak bir normal ifade oluşturalım miktar belirleyicidir. Bu miktar belirleyici sıfır veya daha fazlasını görebilirsiniz.

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

API çağrısı:

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

Politika geçerli mi? Hayır "*" niceleyici, "c" olan önceki karakterin sıfır veya daha fazla tekrarıyla eşleşir.

API Çağrısı:

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

Politika geçerli mi? Evet, çünkü joker karakter, önceki karakterin sıfır veya daha fazlasıyla eşleşir.

Daha sonra "?" alanını kullanıyoruz. önceki karakterle bir kez eşleşen miktar belirleyici veya mümkün değil.

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

API çağrısı:

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

Politika geçerli mi? Evet. "?" miktar belirleyici sıfır veya bir oluşumla eşleşir bir "a" olan öncelikli karakter.

API Çağrısı:

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

Politika geçerli mi? Evet. "?" miktar belirleyici biriyle eşleşir veya hiçbiri gelmemelidir. Bu durumda "a" karakteri olmadığından koşul doğru olarak değerlendirilir.

API Çağrısı:

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

Politika uygulanıyor mu? Hayır. "?" miktar belirleyici, öncekinden biriyle eşleşir o "a" karakteridir.

Daha sonra "[abc]" alanını kullanıyoruz. "gruplandırma" normal ifade stiline sahip olması gerekir. Bu, "a" karakterleri veya "b" veya "c".

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

API çağrısı:

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

Politika geçerli mi? Evet. Burada normal ifadeler kullanıyoruz ve "[cbr]" ifade "c", "b" veya "r" ile eşleşir. Aşağıdaki aramalar da eşleşme olarak kabul edilir:

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

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

Ancak bu bir eşleşme değildir:

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

Soru: JavaRegex operatörü büyük/küçük harfe duyarlıdır mı?

Evet. Aşağıdaki gibi bir koşulunuz olduğunu varsayalım:

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

API çağrısı:

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

Politika uygulanıyor mu? Evet, normal ifade, önceki karakterden sıfır veya bir tanesiyle ("a") eşleşir.

API çağrısı:

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

Soru: Politika uygulanıyor mu?

Hayır, çünkü büyük "A" harfi küçük harfli "a" ile eşleşmez.

MatchesPath

MatchesPath operatörü "~/" şeklinde de belirtilebilir. Bu operatör, Matches (~) ve JavaRegex (~~) operatörlerine biraz benzer. Ancak MatchesPath tamamen farklıdır.

Bu operatörün bir yola bir dizi parça olarak baktığını unutmayın. Dolayısıyla, /animals/cats/wild gibi, yolu istediğiniz zaman "/animals", "/cats" ve "/wild".

MatchesPath operatörü, iki joker karakter gösterimini kullanmanıza olanak tanır: tek bir yıldız işareti (*) ve bir çift yıldız işareti (**). Tek yıldız işareti bir yol öğesiyle eşleşir. Çift yıldız işareti şunlarla eşleşir: birçok yol öğesi vardır.

Bunu bir örnek üzerinde inceleyelim. Bu örnekte, Edge'de isteğin yol son ekini depolayan yerleşik bir değişken olan proxy.pathsuffix değişkenini test ediyoruz. Ancak dilerseniz dize içeren herhangi bir akış değişkeninin değerini test eder.

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

Soru: Hangi proxy yolu soneki, SomePolicy'nin yürütülmesine neden olur?

API çağrısı:

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

Soru: Politika uygulanıyor mu?

Hayır, çünkü koşul "/*" tarafından belirtildiği gibi "/animals"den sonra başka bir yol öğesi gerektirir.

API çağrısı:

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

Politika geçerli mi? Evet, yolun başka bir yol öğesi var ( "/animals/"), ancak bu alan boş.

API Çağrısı:

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

Politika geçerli mi? Evet, çünkü yolda açıkça bir öğe ("/cats") var "/animals" ifadesinden sonra gelen

API Çağrısı:

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

Soru: Bu politika yürürlüğe giriyor mu?

Hayır, tek yıldız işareti yalnızca bir yol öğesiyle eşleştiği ve bu API'de "/animals" ifadesinden sonra birden fazla öğe var.

Şimdi çift yıldız işaretini kullanalım:

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

Soru: Hangi proxy yolu soneki, SomePolicy'nin yürütülmesine neden olur?

API çağrısı:

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

Politika geçerli mi? Hayır, çünkü koşul "/**" ile belirtilen en az bir yol öğesi gerektirir.

API çağrısı:

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

Politika uygulanıyor mu?

Evet, yolda başka bir yol öğesi var ("/animals/"den sonraki kısım) ancak bu öğe boş.

API Çağrısı:

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

Politika geçerli mi?

Evet, çünkü yol "/animals"den sonra gelen en az bir öğe içeriyor.

API Çağrısı:

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

Politika uygulanıyor mu?

Evet, çünkü yolda gelirden sonra gelen birden fazla öğe var "/animals"

Yıldız işaretlerini karıştırma

Daha da hassaslaştırmak için tek (*) ve çift (**) yıldız işaretinin kombinasyonlarını kullanabilirsiniz. yol eşleştirmeyi kullanabilirsiniz.

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

API çağrısı:

Bu API çağrılarının tümü bir eşleşme oluşturur:

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

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

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

API kaynakları

RESTful hizmetler, API kaynaklarından oluşan koleksiyonlardır. API kaynağı, URI yoludur parçasını tanımlar. Örneğin, Hizmetiniz hava durumu raporları ve hava durumu tahminleri sağlıyorsa arka uç hizmetiniz iki API kaynağı vardır:

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

Daha fazla bilgi

Bir API proxy'si oluşturduğunuzda (İlk API proxy'nizi oluşturma bölümünde gösterildiği gibi), en azından arka uç hizmetinizle eşlenen takma ad temel URL'sini ekleyin. Örneğin:

Arka uç temel URL'si	Yeni/eşdeğer API proxy'si URL'si
http://mygreatweatherforecast.com	http://{your_org}-{environment}.apigee.net/mygreatweatherforecast

Bu noktada, her iki temel URL'yi kullanarak arka ucunuza API çağrıları yapabilirsiniz. Ancak API proxy URL'sini kullandığınızda işler ilginçleşmeye başlar.

API proxy'sini kullandığınızda Edge'in toplamaya başladığı API analizlerine ek olarak proxy'ler, arka uçtaki kaynaklarla eşleşen koşullu akışlar tanımlamanıza da olanak tanır. Esasında, "eğer /reports kaynağına bir GET çağrısı geliyor, Edge'in bir işlem yapması gerekiyor."

Aşağıdaki resimde, aynı arka uç olmalıdır. Biri proxy'si olmayan kaynak URL'si, diğeri ise aynı arka uç kaynağına koşullu akış sağlar. Koşullu akışları daha ayrıntılı olarak açıklayacağız bölümüne göz atın.

API proxy'leri belirli arka uç kaynaklarıyla nasıl eşlenir?

Arka uç hizmetinin temel URL'sine eşlenmiş bir API proxy URL'siyle ( proxy aracılığıyla), /reports gibi belirli kaynaklara koşullu akışlar ekleyebilirsiniz. ve daha önce bahsedilen /forecasts kaynak.

Edge'in "bir şey yapmasını" istediğinizi varsayalım telefon görüşmeleri geldiğinde /reports veya /forecasts kaynak. Şu anda Edge'e söyleyemezsiniz ne yapması gerektiğini anlatmalıdır. Bunu koşullarla yapabilirsiniz. Edge API proxy'nizde şunun için koşullu akışlar oluşturabilirsiniz: /reports ve /forecasts. Kavramsal amaçlarla aşağıdaki API proxy XML bu koşulların nasıl görünebileceğini gösterir.

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

Bu koşullar, "URL'de /reports ve /forecasts içeren bir GET isteği geldiğinde Edge, bu akışlara eklediğiniz politikalar aracılığıyla size (API geliştirici) ne söylerseniz onu yapar.

Bir koşul karşılandığında Edge'e ne yapacağını söylemeyle ilgili bir örneği burada bulabilirsiniz. Aşağıdaki API'de proxy XML'i kullanır. https://yourorg-test.apigee.net/mygreatweatherforecast/reports, Edge yürütülür "XML-to-JSON-1" yanıt vermem gerekir.

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

Bu isteğe bağlı koşullu akışlara ek olarak her API proxy'sinde iki varsayılan akış da bulunur: koşullu akışlarınızdan önce yürütülen bir <PreFlow> ve koşullu akışlarınızdan sonra yürütülen bir <PostFlow>. Bunlar, API proxy'sine herhangi bir çağrı yapıldığında politikaları yürütmek için kullanışlıdır. Örneğin, Bir uygulamanın API anahtarını her çağrıyla doğruladığınızda, erişilen arka uç kaynağı ne olursa olsun <PreFlow>, API Anahtarını Doğrula politikası uygulayabilir. Akışlar hakkında daha fazla bilgi için bkz. Akışları yapılandırma.

Arka uç kaynaklarına koşullu akışlar oluşturma

API proxy'sinde arka uç kaynaklarına koşullu akışları tanımlamak tamamen isteğe bağlıdır. Ancak bu koşullu akışlar sayesinde, ayrıntılı yönetim ve uygulama yönetimi takip eder.

Yapabilecekleriniz:

• Yönetimi, API modelinizin anlamını yansıtacak şekilde uygulayın
• Politikaları ve komut dosyası davranışını tek tek kaynak yollarına (URI'ler) uygulama
• Analiz Hizmetleri için ayrıntılı metrikler toplama

Örneğin arka ucunuza farklı mantık türleri uygulamanız gerektiğini varsayalım. /developers to /apps kaynakları.

Bunu yapmak için API proxy'nize iki koşullu akış eklersiniz: /developers ve /apps.

API proxy düzenleyicisi Gezgin bölmesinin Geliştirme görünümünde, Proxy Endpoints bölümünde varsayılanın yanındaki + simgesini tıklayın.

"Yeni Koşullu Akış" penceresinde aşağıdaki anahtar yapılandırmalarını girmeniz gerekir:

• Akış adı: Geliştiriciler
• Koşul Türü: Yol
• Yol: /developers

URI'nin sonunda /developers ile proxy'ye bir çağrı gönderilirse koşul tetiklenir (ve politikalar yürütülür).

Şimdi /apps için koşullu akış ekleyin ve koşulun şu koşulda tetiklenmesini istediğinizi varsayalım: hem URI hem de POST fiilini kullanır. Yapılandırma, takip etmek için:

• Akış Adı: Uygulamalar
• Koşul Türü: Yol ve Eylem
• Yol: /apps
• Fiil: POST

Proxy'ye bir çağrı gönderilirse koşul tetiklenir (ve politikalar yürütülür) URI'nın sonuna /apps ekleyerek ve bir POST fiilini ekleyin.

Gezgin bölmesinde Uygulamalar ve Geliştiriciler için yeni akışlar görürsünüz.

API proxy düzenleyicisinde koşullu akış yapılandırmasını görüntülemek için akışlardan birini seçin kod görünümü:

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

Gördüğünüz gibi API kaynakları, gelen isteğin URI yolunu değerlendiren koşullu akışlardır. (proxy.pathsuffix değişkeni, ProxyEndpoint yapılandırmasında yapılandırılan BasePath'i izleyen isteğin URI'sini tanımlar.)

Tanımladığınız her API kaynağı, API proxy'sindeki koşullu Akış tarafından uygulanır. (Akışları yapılandırma başlıklı makaleyi inceleyin.)

API proxy'sini test ortamına dağıttıktan sonra aşağıdaki istek:

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

koşulun "doğru" olarak değerlendirilmesine neden olur ve bu akış, ilişkili tüm yürütüleceği anlamına gelir.

Aşağıdaki örnek koşul, Sonunda eğik çizgi olan veya olmayan /apps kaynak (/apps veya /apps/**):

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

Bu koşul türü hakkında daha fazla bilgi için Apigee Topluluğu'ndaki Nasıl eşleştirilir? başlıklı makaleyi inceleyin.

Hiyerarşik URI'leri modelleme

Bazı durumlarda hiyerarşik API kaynaklarına sahip olursunuz. Örneğin, Developer Services API, bir geliştiriciye ait tüm uygulamaları listeleme yöntemi sağlar. URI yolu:

/developers/{developer_email}/apps

Bir koleksiyondaki her öğe için benzersiz bir kimliğin oluşturulduğu kaynaklarınız olabilir. Bu kimlikler bazen aşağıdaki gibi ek açıklamalarla belirtilir:

/genus/:id/species

Bu yol, aşağıdaki iki URI için eşit şekilde geçerlidir:

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

Bu yapıyı bir API kaynağında göstermek için joker karakterler kullanabilirsiniz. Örneğin:

/developers/*/apps

/developers/*example.com/apps

/genus/*/species

bu hiyerarşik URI'leri uygun şekilde API kaynakları olarak çözümler.

Bazı durumlarda, Özellikle derin hiyerarşik API'ler için, bir alt boyutun altındaki her şeyi hakkında daha fazla bilgi edinin. Bunu yapmak için kaynak tanımınızda çift yıldız işareti joker karakteri kullanın. Örneğin, aşağıdaki API kaynağını tanımlarsanız:

/developers/**

.

Bu API kaynağı aşağıdaki URI yollarını çözer:

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

Koşullu akış koşulu, API proxy'si tanımında aşağıdaki gibi görünür:

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

Diğer örnekler

RouteRule'a ekli koşul

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

Bir politikaya ekli koşul

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

Koşullu Akış

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

Koşullardaki örnek operatörler

Koşul oluşturmak için kullanılan operatörlere ilişkin bazı örnekleri aşağıda bulabilirsiniz:

• 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

Pratik bir örnek: "/" işaretini yoksayın , yolun sonu

Edge geliştiricileri genellikle şu yol son eklerinin ikisini de işlemek ister: "/cat" ve "/cat/". Bunun nedeni, bazı kullanıcıların veya istemcilerin API'nizi yolun sonuna ek bir eğik çizgi ekleyerek çağırabilmesidir. Bu nedenle, koşullu ifadelerinizde bu durumu ele almanız gerekir. Tam olarak bu kullanım alanı hakkında konuştuk.

İsterseniz bunu normal ifade kullanmadan şu şekilde yapabilirsiniz:

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

Bu iyi bir seçenektir. Açık ve okunabilir olmalıdır.

Ancak, aynı işlemi Regex ile de yapabilirsiniz, bu şekilde. Parantezler, ifadenin normal ifadesi olan kısmıdır, ancak zorunlu değildir.

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

API Çağrıları:

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

Politika uygulanıyor mu? Evet. Normal ifadede "?", karakter anlamına gelir: önceki karakterin sıfır veya bir tekrarıyla eşleşir. Dolayısıyla hem "/cat" ve "/cat/" eşleşmedir.

API Çağrısı:

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

Politika uygulanıyor mu? Hayır. Normal ifade başlar, başka hiçbir şeye izin verilmez.

JavaRegex ile rastgele dizeleri eşleştirme

Bu konudaki tüm örneklerde, yerleşik akış değişkenlerinden birini nasıl eşleştireceğinizi gösteririz: proxy.pathsuffix. Rastgele bir dizede kalıp eşleştirmeyi yapabileceğinizi proxy.pathsuffix gibi yerleşik bir akış değişkeni olup olmadığına bakılmaksızın akış değişkeni kullanabilir.

Örneğin, rastgele bir dizeyi test eden bir koşulunuz varsa, belki de döndürülen bir dize bir kimlik doğrulama sunucusu aramasından döndürülen dizede veya arka uç yükünde eşleşen operatörleri kullanabilirsiniz. JavaRegex kullanırsanız normal ifade karşılaştırılır karşılaştırmanızı sağlar. Konu "abc" ve normal ifade "[a-z]" ise "[a-z]" tam olarak bir alfabe karakteriyle eşleştiği için eşleşme olmaz. "[a-z]+", "[a-z]*" ve "[a-z]{3}" ifadeleri kullanılabilir.

Somut bir örneğe bakalım. Kimlik doğrulama sunucusunun, aşağıdaki gibi bir rol listesi döndürdüğünü varsayalım: virgülle ayrılmış bir dize: "düzenleyici, yazar, konuk".

Düzenleyici rolünün mevcut olup olmadığını test etmek için bu yapı çalışmaz çünkü "düzenleyici" : yalnızca bir kısmını kapsayabilir.

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

Ancak bu inşaat şu şekilde çalışır:

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

Bu yöntem, kelime sonlarını ve dizenin .* öneki ve soneki.

Bu örnekte "editor" (düzenleyici) öğesini de test edebilirsiniz. Eşleşmeler operatörüyle:

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

Ancak daha fazla hassasiyete ihtiyaç duyduğunuz durumlarda JavaRegex genellikle daha iyi bir seçimdir.

JavaRegex ifadelerinde çift tırnaklardan kaçınma

Koşul söz dizimi, bir JavaRegex ifadesinin çift tırnak içine alınmasını gerektirir; Bu nedenle, Çift tırnak işareti içeren normal ifade ifadesi için bunları eşleştirmek için alternatif bir yöntem gerekir. Yanıt Unicode. Örneğin, aşağıdaki gibi çift tırnak içeren bir başlık gönderdiğinizi varsayalım:

 -H 'content-type:multipart/related; type="application/xop+xml"'

Bu başlığı bir normal ifade koşulunda eşleştirmeye çalışırsanız ifade çift tırnak içerdiğinden geçersiz koşul hatası alırsınız:

request.header.Content-Type ~~ "(multipart\/related)(; *type="application\/xop\+xml\")"

Çözüm, ASCII tabanlı çift tırnak işaretlerini Unicode eşdeğeri \u0022 ile değiştirmektir. Örneğin, aşağıdaki ifade geçerlidir ve beklenen sonucu verir:

request.header.Content-Type ~~ "(multipart\/related)(; *type=\u0022application\/xop\+xml\u0022)"