Akış değişkenli koşullar

Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin.
bilgi

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

Bu konuda, çalışma zamanında API yönetimi özelliklerini kod yazmadan dinamik olarak uygulamak için koşulları nasıl kullanacağınız gösterilmektedir.

Koşullu ifadeleri yapılandırma

Koşullu davranış, API proxy'lerinde conditions ve conditions bir kombinasyonu kullanılarak uygulanır. Koşul öğesi kullanılarak koşullu ifade oluşturulur. Aşağıdaki boş bir koşuldur:

<Condition></Condition>

Koşullu ifade oluşturmak için koşullu operatör ve değişken ekleyerek aşağıdaki yapıyı oluşturursunuz:

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

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

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

Koşullar, Arka uç API kaynaklarına koşullu akışlar oluşturma bölümünde açıklanan, arka uç API kaynaklarına yönelik API proxy'si koşullu akışları tanımlamak için kullanılır. Koşulların tam listesi için Koşul referansı bölümüne bakın.

Değişkenler

Koşullar, değişkenlerin değerlerini değerlendirerek işlerini yapar. Değişken, API proxy'si tarafından yürütülen HTTP işleminin veya API proxy yapılandırmasının kendisinin bir özelliğidir. Bir API proxy'si bir uygulamadan istek aldığında Apigee Edge; sistem saati, uygulamanın ağ bilgileri, mesajlardaki HTTP üstbilgileri, API proxy yapılandırması, politika yürütme işlemleri vb. ile ilişkili değişkenlerden oluşan uzun bir liste doldurur. Bu, koşullu ifadeler oluşturmak 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} adı verilen değişkenler olarak mevcuttur. İçerik türü başlığını değerlendirmek için request.header.Content-type değişkenini kullanabilirsiniz. Örneğin request.header.Content-type = "application/json", isteğin içerik türünün JSON olması gerektiğini belirtir.

Bir politikanın yalnızca istek mesajı GET olduğunda uygulanmasına neden olacak bir koşullu ifade oluşturmanız gerektiğini düşünün. Bir isteğin 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>
Şunu da kullanabilirsiniz:
<Condition>request.verb equals "GET"</Condition>

Edge bu gibi bir ifadeyi koşulları değerlendirmek için kullanır. İstekle ilişkilendirilen HTTP fiili GET ise yukarıdaki örnek, doğru olarak değerlendirilir. İstekle ilişkilendirilen HTTP fiili POST ise ifade yanlış olarak değerlendirilir.

Dinamik davranışı etkinleştirmek için Akışlara, Adımlara ve Rota Kurallarına 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 Akışa istediğiniz kadar Politika ekleyebilirsiniz. Koşullu Akış, belirli ölçütleri karşılayan istek veya yanıt mesajları için son derece özelleştirilmiş işleme kuralları oluşturmanızı sağlar.

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

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

GET'ler ve POST'lar için ayrı bir Akış oluşturmak için:

<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ı'na uygulayabilirsiniz. Aşağıdaki Koşul, VerificationApiKey Politikası'nın yalnızca istek mesajı bir POST olması durumunda 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 bunlara Politika ekleyebilir, böylece GET istekleri için bir politika grubunu ve POST istekleri için başka bir politika grubunu zorunlu kılmak üzere API proxy'si etkinleştirebilirsiniz.

Kapsamlı referans bilgileri için aşağıdaki kaynakları inceleyin:

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şul'u, koşulun geçerli olduğu varlığa bir öğ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, değişken olarak sunulan tüm HTTP üstbilgilerinin değerlerini depolar. İstek User-Agent adlı bir HTTP üst bilgisi içeriyorsa bu başlık ve değeri request.header.User-Agent adlı bir değişken olarak depolanır.

Yukarıdaki ProxyEndpoint yapılandırmasıyla birlikte Edge, koşulun doğru olarak değerlendirilip değerlendirilmediğini görmek için request.header.User-Agent değişkeninin değerini kontrol eder.

Koşul doğru olarak değerlendirilirse yani request.header.User-Agent değişkeninin değeri Mozilla ise koşullu Akış yürütülür ve ConvertToJSON adlı XMLtoJSON politikası uygulanır. Aksi takdirde, Akış yürütülmez ve XML yanıtı, istekte bulunan uygulamaya değiştirilmeden (XML biçiminde) döndürülür.

2. Örnek

Yalnızca mobil cihazlar için olmak üzere, yanıt mesajını XML'den JSON'a dönüştürmeniz gereken belirli bir örneği ele alalım. Öncelikle, Weather API'den XML biçimli yanıtı JSON'a dönüştürecek politikayı oluşturun:

<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ı, varsayılan ayarlarla XML'den JSON'a dönüşüm gerçekleştirmesini ve ardından sonucu yeni yanıt mesajına yazmasını bildirir. (Bir request mesajını XML'den JSON'a dönüştürüyorsanız bu değerlerin ikisini de request olarak ayarlamanız yeterlidir.)

Yanıtları XML'den JSON'a dönüştürmek istediğinizden, dönüştürme işlemini gerçekleştirmek için koşullu yanıt akışı yapılandırmanız gerekir. Örneğin, tüm yanıtları istemci uygulamasına döndürülmeden önce 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>

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

Ancak amacınız, istekte bulunan istemci bir mobil cihaz olduğunda yalnızca Hava Durumu raporlarını JSON'a dönüştürmektir. Bu tür dinamik bir davranışı etkinleştirmek için Akış'a bir koşullu ifade eklemeniz gerekir.

Koşullu akışı test etme

Bu örnek istekte HTTP User-Agent başlığı Mozilla olarak ayarlanır. Bu ayar, koşullu ifadenin doğru olarak değerlendirilmesine ve Convert-for-devices koşullu akışının yürütülmesine neden olur.

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

veya Python'un kullanıma sunulduğu yerlerde kullanmak 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 Mozilla dışında bir değerle gönderilen istekler XML biçimli yanıtla sonuçlanır.

$ 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ışındaki koşullarla kalıp eşleştirmenin nasıl kullanılacağı açıklanmaktadır.

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:

Şununla eşleşiyor:

İlk olarak "Eşleşmeler" veya "~" koşullu operatörüne bakalım. Bu iki operatör aynıdır. İngilizce sürüm olan "Eşleşmeler", daha okunabilir bir seçenek olarak kabul edilir.

Özet: "Eşleşmeler" operatörü size iki olasılık sunar. Dizeyi olduğu gibi eşleştirebilir veya "*" karakteriyle joker karakter eşleştirmesi yapabilirsiniz. Tahmin edebileceğiniz gibi, joker karakter sıfır veya daha fazla karakterle eşleşir. Şimdi bunun nasıl olduğuna bakalım.

Aşağıdaki XML'de bir Adım koşulu gösterilmektedir. Koşul doğru olarak değerlendirildiğinde AnyPolicy politikasını yürütür. Bu örnekte, isteğin yol son ekini depolayan, Edge'deki yerleşik bir değişken olan proxy.pathsuffix değişkenini test ediyoruz. Bununla birlikte, dize içeren herhangi bir akış değişkeninin değerini test edebileceğinizi unutmayın. Dolayısıyla bu örnekte, gelen isteğin temel yolu /animals ise ve istek /animals/cat ise yol son eki, "/cat" dizesi olur.

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

Soru: Hangi proxy yolu son eki AnyPolicy'nin yürütülmesine neden olur? Tek bir olasılık var.

API çağrısı:

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

Politika ilerliyor mu? Evet, çünkü proxy yolu son eki "/cat" ile tam olarak eşleşir. Sonek /bat veya /dog ya da "/" veya başka bir şey olursa yürütülmez.

Şimdi, "*" joker karakterini kullandığımız şu 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 ilerliyor mu? Evet, çünkü joker karakter herhangi bir karakterle eşleşir ve "/cat" bir eşleşmedir.

API Çağrısı:

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

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

API Çağrısı:

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

Politika ilerliyor mu? Kesinlikle hayır. 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 ilerliyor mu? Evet, çünkü joker karakter sıfır veya daha fazla karakterle eşleşir.

API Çağrısı:

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

Politika ilerliyor mu? Hayır, "/bat" bir eşleşme değil.

API çağrısı:

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

Politika ilerliyor mu? Evet, joker karakter herhangi bir karakterin sıfır veya daha fazla tekrarıyla eşleşir. Bu nedenle "123" bir eşleşme oluşturur.

API çağrısı:

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

Politika ilerliyor mu? Evet, çünkü joker karakter sıfır veya daha fazla karakterle eşleşir. Bu nedenle "/bird/mouse" bir eşleşme oluşturur. Böyle bir ifadenin, harflerden sonraki her şeyle eşleştiği için sizi nasıl sıkıntıya sokabileceğini unutmayın.

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 ilerliyor mu? Hayır, joker karakter tüm harfle eşleşir (büyük/küçük harfe bakılmaksızın) ancak küçük "a", "A" ile eşleşmez.

API çağrısı:

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

Politika ilerliyor mu? Evet, destek kaydı eşleşiyor.

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

Ayrılmış karakterlerden çıkış yapmak için yüzde "%" 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 ilerliyor mu? Hayır, Eşleşmeler operatörü "c*at" değişmez dizesini arar.

API çağrısı:

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

Soru:Politika yürütülüyor mu?

Evet, bu yol biraz olağandışı olsa da eşleşiyor.

JavaRegex

Gördüğünüz gibi, "Eşleşmeler" operatörü basit durumlar için idealdir. Ancak başka bir operatör ("JavaRegex" veya "~~" operatörü) kullanabilirsiniz. JavaRegex'in daha okunabilir kabul edilmesi dışında bu ikisi aynıdır. Normal ifade kalıbı eşleşmesine izin verdiği, Edge ise Java dilindeki java.util.regex paketindeki sınıflarla aynı kuralları izlediği için JavaRegex olarak adlandırılmıştır. JavaRegex operatörünün çalışma şekli, "Eşleşmeler" operatöründen çok farklıdır. Bu nedenle ikisini karıştırmamak önemlidir.

Özet: "JavaRegex" operatörü, koşullu ifadelerde normal ifade söz dizimini kullanabilmenizi sağlar.

Aşağıdaki kodda bir Adım koşulu gösterilmektedir. Koşul doğru olarak değerlendirilirse AnyPolicy politikasını yürütür. Bu örnekte, isteğin yol son ekini depolayan, Edge'deki yerleşik değişken proxy.pathsuffix değişkenini test ediyoruz. Gelen isteğin temel yolu /animals ise ve istek /animals/cat ise yol son eki, değişmez dize "/cat" olur.

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

Soru: Hangi proxy yolu son eki AnyPolicy'nin yürütülmesine neden olur? Eşleşmeler operatöründe olduğu gibi, bu durumda da yalnızca bir olasılık vardır.

API çağrısı:

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

Politika ilerliyor mu? Evet, çünkü proxy yolu son eki "/cat" ile tam olarak eşleşir. Sonek /bat veya /dog ya da başka bir şey olduğunda yürütülmez.

Şimdi "*" miktar belirleyicisini kullanarak normal ifade oluşturalım. Bu miktar belirleyici, önceki karakterin sıfır veya daha fazla tekrarıyla eşleşir.

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

API çağrısı:

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

Politika ilerliyor mu? Hayır "*" miktar belirleyicisi, öndeki karakterin sıfır veya daha fazla tekrarıyla eşleşir. Bu, "c" karakteridir.

API Çağrısı:

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

Politika ilerliyor mu? Evet, çünkü joker karakter önceki karakterin sıfır veya daha fazla tekrarıyla eşleşir.

Ardından, önceki karakterle bir kez eşleşen veya hiç eşleşmeyen "?" miktar belirleyicisini kullanırız.

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

API çağrısı:

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

Politika ilerliyor mu? Evet. "?" miktar belirleyicisi, "a" olan baştaki karakterin sıfır veya bir tekrarıyla eşleşir.

API Çağrısı:

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

Politika ilerliyor mu? Evet. "?" miktar belirleyicisi, önceki karakterin bir veya hiçbiriyle eşleşir. Bu durumda, "a" karakteri yoktur ve koşul doğru olarak değerlendirilir.

API Çağrısı:

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

Politika ilerliyor mu? Hayır. "?" miktar belirleyicisi, "a" olan önceki karakterden biriyle eşleşir.

Ardından, normal ifade ifadesinin "[abc]" veya "gruplandırma" stilini kullanacağız. "a", "b" veya "c" karakterleriyle eşleşir.

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

API çağrısı:

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

Politika ilerliyor mu? Evet. Burada normal ifadeler kullanıyoruz. "[cbr]" ifadesi "c", "b" VEYA "r" ile eşleşiyor. Bu aramalar da eşleşir:

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

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

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

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

Soru: JavaRegex 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 JavaRegex "/ca?t")</Condition>

API çağrısı:

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

Politika ilerliyor mu? Evet. Normal ifade, "a" olan önceki karakterin sıfır veya biriyle eşleşir.

API çağrısı:

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

Soru: Politika yürütülüyor mu?

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

MatchesPath

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

Ancak, bu operatörün bir yola bir dizi parça olarak baktığını unutmayın. Bu nedenle, yol /animals/cats/wild ise yolu "/animals", "/cats" ve "/wild" bölümlerinden oluşan düşünebilirsiniz.

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

Bunu bir örnek üzerinde inceleyelim. Bu örnekte, isteğin yol son ekini depolayan, Edge'deki yerleşik değişken proxy.pathsuffix değişkenini test ediyoruz. Bununla birlikte, dize içeren herhangi bir akış değişkeninin değerini test edebileceğinizi unutmayın.

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

Soru: Hangi proxy yolu son eki AnyPolicy'nin yürütülmesine neden olur?

API çağrısı:

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

Soru: Politika yürütülüyor mu?

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

API çağrısı:

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

Politika ilerliyor mu? Evet, yolun başka bir yol öğesi ("/animals/"den sonraki bölüm) var ancak sadece boş.

API Çağrısı:

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

Politika ilerliyor mu? Evet, çünkü yolda açıkça "/animals" sonrasında gelen bir öğe ("/cats") var

API Çağrısı:

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

Soru: Politika yürütülüyor mu?

Hayır, çünkü tek yıldız işareti yalnızca bir yol öğesiyle eşleşir ve bu API'nin "/animals" ifadesinden sonra birden fazla öğesi vardır.

Ş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 son eki AnyPolicy'nin yürütülmesine neden olur?

API çağrısı:

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

Politika ilerliyor mu? Hayır, çünkü koşul için "/**" tarafından belirtilen en az bir takip eden yol öğesi gerekir.

API çağrısı:

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

Politika yürütülüyor mu?

Evet, yolun başka bir yol öğesi ("/animals/"den sonraki bölüm) var ancak sadece boş.

API Çağrısı:

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

Politika yürütülüyor mu?

Evet, çünkü yolun "/animals" ifadesinden sonra gelen en az bir öğesi var

API Çağrısı:

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

Politika yürütülüyor mu?

Evet, çünkü yolun "/animals" ifadesinden sonra gelen birden fazla öğesi var

Karıştırma yıldızları

Yol eşleşmenizi daha da hassaslaştırmak için tek (*) ve çift (**) yıldız işaretlerinin kombinasyonlarını 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 kaynağı koleksiyonlarıdır. API kaynağı, geliştiricilerin API'nizi çağırarak erişebileceği bazı varlıkları tanımlayan URI yolu parçasıdır. Örneğin, hizmetiniz hava durumu raporları ve hava durumu tahminleri sağlıyorsa arka uç hizmetiniz iki API kaynağı tanımlayabilir:

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

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şleşen bir takma ad temel URL'si oluşturmuş olursunuz. Örneğin:

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

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

Proxy'ler, API proxy'sini kullandığınızda Edge'in toplamaya başladığı API analizlerinin yanı sıra arka ucunuzdaki kaynaklarla eşlenen koşullu akışlar tanımlamanızı sağlar. Özünde, "/reports kaynağına bir GET çağrısı gelirse Edge bir şey yapmalıdır."

Aşağıdaki resimde, aynı arka uca erişen iki URL arasındaki davranış farkı gösterilmektedir. Biri proxy uygulanmayan kaynak URL'si, diğeri ise aynı arka uç kaynağına koşullu akış sağlayan bir Edge API proxy'sidir. Koşullu akışları aşağıda daha ayrıntılı olarak açıklayacağız.

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

Arka uç hizmetinin temel URL'siyle eşlenen bir API proxy URL'si ile (proxy oluşturduğunuzda) belirli kaynaklara (daha önce bahsedilen /reports ve /forecasts kaynakları gibi) koşullu akışlar ekleyebilirsiniz.

/reports veya /forecasts kaynaklarına çağrı geldiğinde Edge'in "bir işlem yapmasını" istediğinizi varsayalım. Bu noktada Edge'e ne yapması gerektiğini söylemiyor, sadece bu kaynaklara yapılan çağrıları dinliyor olması gerekiyor. Bunu koşullarla yaparsınız. Edge API proxy'nizde /reports ve /forecasts için koşullu akışlar oluşturabilirsiniz. Kavramsal açıdan bu koşulların nasıl görünebileceğini aşağıdaki API proxy XML'sinde görebilirsiniz.

<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 arasında "GET isteği, URL'de /reports ve /forecasts ile geldiğinde, Edge sizin (API geliştiricisi) istenen her işlemi, bu akışlara eklediğiniz politikalar aracılığıyla gerçekleştirir.

Şimdi, bir koşul karşılandığında Edge'e ne yapması gerektiğini bildirmeyle ilgili bir örneği aşağıda bulabilirsiniz. Aşağıdaki API proxy XML'sinde, https://yourorg-test.apigee.net/mygreatweatherforecast/reports öğesine bir GET isteği gönderildiğinde, Edge yanıtta "XML-to-JSON-1" politikasını yürütür.

<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'sinin iki varsayılan akışı da vardır: koşullu akışlarınızdan önce yürütülen <PreFlow> ve koşullu akışlarınızdan sonra yürütülen <PostFlow>. Bunlar, API proxy'sine herhangi bir çağrı yapıldığında politikaları yürütmek için yararlıdır. Örneğin, erişilen arka uç kaynağına bakılmaksızın, her çağrıda bir uygulamanın API anahtarını doğrulamak istiyorsanız <PreFlow> öğesine bir Doğrulama API Anahtarı politikası yerleştirebilirsiniz. Akışlar hakkında daha fazla bilgi için Akışları yapılandırma bölümüne bakın.

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, ayrıntılı yönetim ve izleme olanağı sunar.

Şunları yapabileceksiniz:

  • Yönetimi, API modelinizin anlamını yansıtacak şekilde uygulayın
  • Bağımsız kaynak yollarına (URI'ler) politika ve komut dosyası uygulanmış davranış uygulama
  • Analytics hizmetleri için ayrıntılı metrikler toplama

Örneğin, arka ucunuza /developers, /apps kaynaklarınıza farklı mantık türleri uygulamanız gerektiğini düşünün.

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

API proxy düzenleyicisi Gezgini bölmesinin Geliştirme görünümünde, Proxy Uç Noktaları'nda varsayılanın yanındaki + simgesini tıklayın.

"Yeni Koşullu Akış" penceresinde aşağıdaki temel yapılandırmaları girersiniz:

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

URI'nın 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 bir istekteki hem URI hem de POST fiilinde tetiklenmesini istediğinizi varsayalım. Yapılandırma, aşağıdakilerin ayarlanmasını içerir:

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

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

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

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

<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'sinde koşullu bir Akış tarafından uygulanır. (Akışları yapılandırma bölümünü 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 politikalarla birlikte yürütülür.

Aşağıdaki örnek koşul, /apps kaynağına sonlarında eğik çizgiyle (/apps veya /apps/**) yapılan veya olmayan çağrıları tanımak için bir Java normal ifadesi kullanır:

<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ığına göz atın.

Hiyerarşik URI'leri modelleme

Bazı durumlarda hiyerarşik API kaynaklarınız olabilir. Örneğin, Developer Services API bir geliştiriciye ait olan tüm uygulamaların listelenmesi için bir yöntem sağlar. URI yolu şu şekildedir:

/developers/{developer_email}/apps

Koleksiyondaki her varlık için benzersiz bir kimliğin oluşturulduğu ve bazen aşağıdaki gibi ek açıklama eklenen kaynaklarınız olabilir:

/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 de derin hiyerarşik API'ler için belirli bir URI parçasının altındaki her şeyi çözümlemek isteyebilirsiniz. Bunu yapmak için kaynak tanımınızda çift yıldız joker karakteri kullanın. Örneğin, şu API kaynağını tanımlarsanız:
/developers/**

Bu API kaynağı, aşağıdaki URI yollarını çözümler:

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

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

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

Diğer örnekler

Koşul RouteRule'a eklendi

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

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şullarda örnek operatörler

Aşağıda, koşul oluşturmak için kullanılan operatörlere bazı örnekler verilmiştir:

  • 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: Bir yolun sonundaki "/" karakterini yok

Edge geliştiricileri genellikle "/cat" ve "/cat/" yol son eklerinin ikisini de işlemek ister. Bunun nedeni, bazı kullanıcıların veya istemcilerin API'nizi yolun sonunda ekstra eğik çizgiyle çağırabilmesi ve koşullu ifadelerinizde bu son ekin işlenebilmesidir. Bu kullanım alanı Apigee Topluluğu'nda ele alınmıştır.

Dilerseniz bu işlemi şu şekilde Normal İfade kullanmadan 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. Anlaşılır ve okunabilir.

Aynı şeyi Regex için de şu şekilde yapabilirsiniz. Parantezler ifadenin normal ifade bölümünü gruplandırmak için kullanılır, ancak gerekli 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 ilerliyor mu? Evet. Normal ifadede "?" karakterinin şu anlama geldiğini unutmayın: Önceki karakterin sıfır veya bir tekrarıyla eşleşme. Bu nedenle, hem "/cat" hem de "/cat/" eşleşmedir.

API Çağrısı:

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

Politika ilerliyor mu? Hayır. Normal ifade, sıfır veya önceki karakterin yalnızca bir tekrarıyla eşleşir ve başka hiçbir şeye izin verilmez.

Rastgele dizeleri JavaRegex ile eşleştirme

Bu konudaki örneklerin tümünde, yerleşik akış değişkenlerinden biriyle nasıl eşleştirileceği gösterilmektedir: proxy.pathsuffix. Proxy.pathsuffix gibi yerleşik bir akış değişkeni olsun ya da olmasın, herhangi bir rastgele dize veya akış değişkeni üzerinde kalıp eşleştirme yapabileceğinizi bilmenizde fayda vardır.

Örneğin, rastgele bir dizeyi, arka uç yükünde döndürülen bir dizeyi veya kimlik doğrulama sunucusu aramasından döndürülen bir dizeyi test eden bir koşulunuz varsa bunu test etmek için eşleşen operatörleri kullanabilirsiniz. JavaRegex kullanıyorsanız normal ifade, tüm konu dizesiyle karşılaştırılır. Konu "abc" ve normal ifade "[a-z]" ise eşleşme olmaz çünkü "[a-z]" tam olarak bir alfa karakteriyle eşleşir. "[a-z]+" ifadesi, "[a-z]*" ve "[a-z]{3} gibi çalışır.

Bunu somut bir örnekle açıklayalım. Kimlik doğrulama sunucusunun, "düzenleyici, yazar, konuk" şeklinde virgülle ayrılmış bir dize olarak rol listesi döndürdüğünü varsayalım.

"Düzenleyici" tüm dizenin yalnızca bir parçası olduğundan, düzenleyici rolünün varlığını test etmek için bu yapı çalışmaz.

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

Ancak, bu yapım şu şekilde işler:

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

Dizenin .* öneki ile son ekini içeren diğer bölümlerini de dikkate aldığı için bu işlev işe yarar.

Bu örnekte, Eşleşmeler operatörüyle "editor" kelimesini de test edebilirsiniz:

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

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

JavaRegex ifadelerinde çift tırnak işaretlerine çıkış ekleme

Koşul söz dizimi, JavaRegex ifadesinin çift tırnak içine alınmasını gerektirir. Bu nedenle, çift tırnak içeren bir normal ifadeniz varsa bunları eşleştirmek için alternatif bir yola ihtiyacınız vardır. Cevap Unicode. Örneğin, aşağıdaki gibi çift tırnak içeren bir üstbilgi girdiğinizi varsayalım:
 -H 'content-type:multipart/related; type="application/xop+xml"'
Bu başlığı bir normal ifade koşulunda eşleştirmeyi denerseniz, ifadede çift tırnak bulunduğu için 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 olan \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)"