Akış değişkenli koşullar

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

Koşullu ifadeler, tüm programlama dillerinde yaygın olarak kullanılan bir kontrol yapısıdır. API proxy yapılandırması, bir programlama dilinde olduğu gibi Flows, Policies, Steps ve RouteRules için koşullu ifadeleri destekler. Koşullu ifadeler tanımlayarak API'niz için dinamik davranış 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 bir arka uç URL'sine yönlendirme gibi işlemler yapmanıza olanak tanır.

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

Koşullu ifadeleri yapılandırma

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

<Condition></Condition>

Koşullu ifade oluşturmak için koşullu bir 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) yer alır. Okunabilirliği artırmak için koşulları 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, Arka uç API kaynaklarına koşullu akışlar oluşturma bölümünde açıklandığı gibi arka uç API kaynaklarına yönelik API proxy koşullu akışlarını tanımlamak için kullanılır. Koşulların 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, bir API proxy'si tarafından yürütülen bir HTTP işleminin özelliği veya API proxy'si 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ütmeleri gibi öğelerle ilişkili uzun bir değişken listesini 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 başlıkları request.header.{header_name} adlı değişkenler olarak kullanılabilir. Bu nedenle, Content-type üstbilgisini 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 gösterir.

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'dır. Operatör: =.

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

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

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

Dinamik davranışı etkinleştirmek için Koşulları Akışlara, Adımlara ve RouteRule'lara 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 mesajları için son derece özelleşmiş işleme kuralları oluşturmanıza olanak tanır.

Ö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 istekleri için bir akış, POST istekleri 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 bunlara politikalar ekleyebilir, böylece bir API proxy'sinin GET istekleri için bir politika grubu, POST istekleri için ise başka bir politika grubu uygulamasını sağlayabilirsiniz.

Kapsamlı referans bilgileri için aşağıdaki kaynaklara bakın:

• Akış değişkenleri referansı
• Koşullar 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, koşulun 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>

Edge, bir uygulamadan alınan her istek için mevcut tüm HTTP başlıklarının değerlerini değişken olarak depolar. İ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şken olarak depolanır.

Yukarıdaki ProxyEndpoint yapılandırması göz önüne alındığında, 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 değişkenin değeri request.header.User-Agent, Mozilla'ye eşitse) 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

Yanıt mesajını XML'den JSON'a dönüştürmeniz gereken belirli bir örneği ele alalım. Ancak bu dönüşüm yalnızca mobil cihazlar için geçerli olacak. İlk olarak, Hava Durumu API'sinden gelen 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üştürme işlemini gerçekleştirmesini ve ardından sonucu yeni yanıt mesajına yazmasını söyler. (Bir istek 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ğiniz için dönüştürme işlemini gerçekleştirmek üzere koşullu bir yanıt akışı yapılandırmanız gerekir. Ö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 olur.

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

Koşullu akışı test etme

Bu örnek istekte, HTTP User-Agent üst bilgisi Mozilla olarak ayarlanır. Bu nedenle, koşullu ifade doğru olarak değerlendirilir ve koşullu akış Convert-for-devices yürütülür.

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

Alternatif olarak, Python'un kullanılabildiği yerlerde kolay okunabilir ş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 Mozilla değerinden farklı bir değerle gönderilen istekler XML biçimli bir 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ışında koşullarla birlikte 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:

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

Eşleşmeler

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

Özet: "Eşleşmeler" operatörü size iki olasılık sunar. Dizeyi tam olarak eşleştirin veya "*" ile joker karakter eşleşmesi yapın. Bekleyebileceğiniz gibi, joker karakter sıfır veya daha fazla karakterle eşleşir. Bunun nasıl çalıştığına bakalım.

Aşağıdaki XML'de bir Adım koşulu gösterilmektedir. Koşul doğru olarak değerlendirildiğinde SomePolicy politikasını yürütür. Bu örnekte, Edge'de isteğin yol sonekini depolayan yerleşik bir değişken olan proxy.pathsuffix değişkenini test ediyoruz. Ancak, dize içeren herhangi bir akış değişkeninin değerini test edebileceğinizi unutmayın. Bu durumda, gelen isteğin temel yolu /animals ise ve istek /animals/cat ise yol soneki, "/cat" dizesidir.

    <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? Tek bir olasılık vardır.

API çağrısı:

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

Politika yürütülüyor mu? Evet, çünkü proxy yolu soneki "/cat" ile tam olarak eşleşiyor. Sonek /bat veya /dog ya da "/" veya başka bir şeyse yürütülmez.

Şimdi de joker karakter "*" kullandığımız şu koşullu ifadeye bakalım:

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

API çağrısı:

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

Politika yürütülüyor mu? Evet, çünkü joker karakter herhangi bir karakterle eşleşir ve "/cat eşleşme olur.

API Çağrısı:

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

Politika yürütülüyor mu? Evet, çünkü joker karakter herhangi bir karakterle eşleşir. Bu nedenle "/bat" eşleşme olur.

API Çağrısı:

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

Politika yürütülüyor mu? Elbette değil. Joker karakter "o" ile eşleşse de "wl" harfleri eşleşmez.

Şimdi, yıldız işaretini sonekin sonuna taşıyalım:

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

API çağrısı:

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

Politika yürütülüyor mu? Evet, çünkü joker karakter herhangi bir karakterin sıfır veya daha fazla örneğini eşleştirir.

API Çağrısı:

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

Politika yürütülüyor mu? Hayır, "/bat" eşleşmiyor.

API çağrısı:

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

Politika yürütülüyor mu? Evet, joker karakter herhangi bir karakterin sıfır veya daha fazla örneğiyle eşleşir. Bu nedenle "123" eşleşme oluşturur.

API çağrısı:

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

Politika yürütülüyor mu? Evet, çünkü joker karakter herhangi bir karakterin sıfır veya daha fazla örneğiyle eşleşir. Bu nedenle "/bird/mouse" eşleşme oluşturur. Bu gibi bir ifadenin, değişmez karakterlerden sonra gelen her şeyi eşleştirdiği için sizi nasıl zor duruma düşürebileceğine dikkat edin.

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

Evet. Şu 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 yürütülüyor mu? Hayır, joker karakter büyük/küçük harf fark etmeksizin herhangi bir harfle eşleşir ancak küçük harf "a", büyük harf "A" ile eşleşmez.

API çağrısı:

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

Politika yürütülüyor mu? Evet, büyük/küçük harf eşleşiyor.

Soru: Eşleşme operatörüyle karakterleri nasıl çıkarabilirim?

Ayrılmış karakterlere çıkış karakteri eklemek 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 yürütülüyor mu? Hayır, Matches operatörü "c*at" 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 alışılmadık olsa da eşleşiyor.

JavaRegex

Gördüğünüz gibi, "Matches" operatörü basit durumlar için idealdir. Ancak başka bir operatör olan "JavaRegex" veya "~~" operatörünü kullanabilirsiniz. Bu ikisi aynı operatördür. Ancak JavaRegex'in daha okunabilir olduğu düşünülür. Normal ifade kalıbı eşleştirmesine izin verdiği için JavaRegex olarak adlandırılır. Edge, Java dilindeki java.util.regex paketi içindeki sınıflarla aynı kuralları izler. JavaRegex operatörünün çalışma şekli Matches 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 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, Edge'de isteğin yol sonekini depolayan yerleşik bir değişken olan proxy.pathsuffix değişkenini test ediyoruz. Gelen isteğin temel yolu /animals ise ve istek /animals/cat ise yol soneki, "/cat" dizesidir.

    <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? Matches operatöründe olduğu gibi, bu durumda yalnızca bir olasılık vardır.

API çağrısı:

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

Politika yürütülüyor mu? Evet, çünkü proxy yolu soneki "/cat" ile tam olarak eşleşiyor. Sonek /bat veya /dog ya da başka bir şeyse yürütülmez.

Şimdi "*" nicelendiricisini kullanarak bir normal ifade oluşturalım. Bu nicelik belirleyici, önceki karakterin sıfır veya daha fazla örneğiyle eşleşir.

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

API çağrısı:

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

Politika yürütülüyor mu? Hayır "*" nicelendiricisi, önceki karakterin (yani "c") sıfır veya daha fazla örneğiyle eşleşir.

API Çağrısı:

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

Politika yürütülüyor mu? Evet, çünkü joker karakter önceki karakterin sıfır veya daha fazla örneğiyle eşleşir.

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

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

API çağrısı:

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

Politika yürütülüyor mu? Evet. "?" niceleyicisi, "a" olan önceki karakterin sıfır veya bir tekrarıyla eşleşir.

API Çağrısı:

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

Politika yürütülüyor mu? Evet. "?" niceleyicisi, önceki karakterin bir veya hiçbiriyle eşleşir. 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 yürütülüyor mu? Hayır. "?" nicelendiricisi, önceki karakterlerden birini eşleştirir. Bu karakter de "a"dir.

Ardından, normal ifade stilinde "[abc]" veya "gruplandırma" kullanırı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 yürütülüyor mu? Evet. Burada normal ifadeler kullanıyoruz ve "[cbr]" ifadesi "c", "b" VEYA "r" ile eşleşiyor. 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 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ı?

Evet. Şu 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 yürütülüyor mu? Evet, normal ifade, önceki karakterin (yani "a") sıfır veya bir örneğiyle eşleşiyor.

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" harfiyle eşleşmiyor.

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 yolu bir dizi bölüm olarak değerlendirdiğini unutmayın. Bu nedenle, yol /animals/cats/wild ise yolu "/animals", "/cats" ve "/wild" bölümlerinden oluşuyormuş gibi düşünebilirsiniz.

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

Bunu bir örnek üzerinde inceleyelim. Bu örnekte, Edge'de isteğin yol sonekini depolayan yerleşik bir değişken olan proxy.pathsuffix değişkenini test ediyoruz. Ancak 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 soneki SomePolicy'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, "/*" ile belirtildiği gibi "/animals"dan sonra başka bir yol öğesi gerektiriyor.

API çağrısı:

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

Politika yürütülüyor mu? Evet, yolda başka bir yol öğesi (the part after "/animals/") var ancak bu öğe boş.

API Çağrısı:

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

Politika yürütülüyor mu? Evet, çünkü yolda "/animals" öğesinden sonra 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'de "/animals"dan sonra birden fazla öğe 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 soneki SomePolicy'nin yürütülmesine neden olur?

API çağrısı:

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

Politika yürütülüyor mu? Hayır, çünkü koşul, "/**" ile belirtilen aşağıdaki yol öğelerinden en az birini gerektiriyor.

API çağrısı:

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

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

Evet, yolda başka bir yol öğesi (the part after "/animals/") var ancak bu öğe boş.

API Çağrısı:

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

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

Evet, çünkü yolda "/animals"dan sonra gelen en az bir öğe var.

API Çağrısı:

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

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

Evet, çünkü yolda "/animals" işaretinden sonra gelen birden fazla öğe var.

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

Yol eşleştirmenizi daha da hassaslaştırmak için tek (*) ve çift (**) yıldız 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ü 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ının koleksiyonlarıdır. API kaynağı, geliştiricilerin API'nizi çağırarak erişebileceği bir URI yolu parçasıdır. Örneğin, hizmetiniz hava durumu raporları ve hava durumu tahminleri sunuyorsa 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şlenen bir takma ad tabanlı URL oluşturursunuz. Örneğin:

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

Edge, API proxy'sini kullandığınızda API analizlerini toplamaya başlar. Ayrıca proxy'ler, arka uçtaki kaynaklarla eşlenen koşullu akışlar tanımlamanıza da olanak tanır. Özetle, "Bir GET çağrısı /reports kaynağına gelirse Edge bir işlem yapmalıdır."

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

API proxy'lerinin belirli arka uç kaynaklarıyla nasıl eşlendiği

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

Edge'in /reports veya /forecasts kaynaklarına gelen aramalar olduğunda "bir şeyler yapmasını" istediğinizi varsayalım. Bu noktada Edge'e ne yapması gerektiğini söylemiyorsunuz, yalnızca bu kaynaklara yapılan çağrıları dinlemesi gerektiğini belirtiyorsunuz. Bunu koşullarla yaparsınız. Edge API proxy'nizde /reports ve /forecasts için koşullu akışlar oluşturabilirsiniz. Kavramsal amaçlarla, aşağıdaki API proxy XML'sinde bu koşulların nasıl görünebileceği gösterilmektedir.

<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 ile bir GET isteği geldiğinde Edge, bu akışlara eklediğiniz politikalar aracılığıyla size (API geliştiricisi) ne yapmasını söylerseniz onu yapar.

Şimdi de bir koşul karşılandığında Edge'e ne yapması gerektiğini söyleme örneğini inceleyelim. Aşağıdaki API proxy'si XML'sinde, https://yourorg-test.apigee.net/mygreatweatherforecast/reports adresine bir GET isteği gönderildiğinde Edge, yanıttaki "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'si iki varsayılan akışla birlikte gelir: 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>. Bu politikalar, bir API proxy'sine herhangi bir çağrı yapıldığında politikaları yürütmek için kullanışlı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> üzerine bir API Anahtarını Doğrula politikası yerleştirebilirsiniz. Akışlar hakkında daha fazla bilgi için Akışları yapılandırma başlıklı makaleyi inceleyin.

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

API proxy'sinde arka uç kaynaklarına yönelik 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 uygulamanıza olanak tanır.

Şunları yapabilirsiniz:

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

Örneğin, arka uçtaki /developers ve /apps kaynaklarına farklı türde mantık uygulamanız gerektiğini düşünün.

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

API proxy'si düzenleyicisinin Gezgin bölmesindeki Geliştir 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 anahtar yapılandırmalarını girersiniz:

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

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

Şimdi /apps için koşullu bir akış ekleyin ve koşulun hem URI hem de bir istekteki POST fiili üzerinde tetiklenmesini istediğinizi varsayın. Yapılandırma için aşağıdakilerin ayarlanması gerekir:

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

URI'nin sonunda /apps ile ve 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.

Koşullu akış yapılandırmasını API proxy düzenleyicisinin kod görünümünde 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ı yalnızca 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ışla uygulanır. (Bkz. Akışları yapılandırma.)

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 yapılan aramaları, sonunda eğik çizgi olsun veya olmasın (/apps ya da /apps/**) tanımak için Java normal ifadesini kullanır:

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

Bu tür koşullar hakkında daha fazla bilgi için Apigee Topluluğu'ndaki Ne olursa olsun eşleştirme ... başlıklı makaleyi inceleyin.

Hiyerarşik URI'leri modelleme

Bazı durumlarda hiyerarşik API kaynaklarınız olur. Örneğin, Developer Services API, bir geliştiriciye ait tüm uygulamaları listelemek için bir yöntem sunar. 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 şu şekilde açıklama olarak eklenir:

/genus/:id/species

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

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

Bu yapıyı bir API kaynağında temsil etmek için joker karakterler kullanabilirsiniz. Örneğin:

/developers/*/apps

/developers/*example.com/apps

/genus/*/species

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

/developers/**

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

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

Koşullu akış koşulunun API proxy tanımında nasıl görüneceği aşağıda açıklanmıştır:

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

Diğer örnekler

RouteRule'a eklenen 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 eklenen 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: Bir yolun sonundaki "/" karakterini yoksayma

Edge geliştiricileri genellikle "/cat" ve "/cat/" olmak üzere bu iki yol sonekini de işlemek ister. Bunun nedeni, bazı kullanıcıların veya istemcilerin API'nizi yolun sonunda fazladan bir eğik çizgiyle çağırması ve koşullu ifadelerinizde bunu işleyebilmeniz gerekmesidir. Bu kullanım alanı Apigee Topluluğu'nda ele alınmıştır.

İsterseniz bu işlemi normal ifade kullanmadan da 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. Net ve okunabilir olmalıdır.

Aynı işlemi Regex ile de yapabilirsiniz. Parantezler, ifadenin normal ifade bölümünü gruplandırmak için kullanılı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 yürütülüyor mu? Evet. Normal ifadelerde "?" karakterinin, önceki karakterin sıfır veya bir tekrarıyla eşleşme anlamına geldiğini unutmayın. Bu nedenle hem "/cat" hem de "/cat/" eşleşir.

API Çağrısı:

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

Politika yürütülüyor mu? Hayır. Normal ifade, önceki karakterin sıfır veya yalnızca bir kez oluşmasıyla eşleşir ve 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ğimiz gösterilmektedir: proxy.pathsuffix. proxy.pathsuffix gibi yerleşik bir akış değişkeni olup olmadığına bakılmaksızın, herhangi bir rastgele dize veya akış değişkeninde kalıp eşleştirme yapabileceğinizi bilmek faydalıdır.

Örneğin, rastgele bir dizeyi test eden bir koşulunuz varsa (belki arka uç yükünde döndürülen bir dize veya kimlik doğrulama sunucusu aramasından döndürülen bir dize) bunu test etmek için eşleşme operatörlerini kullanabilirsiniz. JavaRegex kullanıyorsanız normal ifade, konu dizesinin tamamıyla karşılaştırılır. Konu "abc" ise 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}" ifadeleri gibi çalışır.

Somut bir örneğe bakalım. Kimlik doğrulama sunucusunun, rolleri virgülle ayrılmış bir dize olarak döndürdüğünü varsayalım: "editor, author, guest".

Düzenleyici rolünün varlığını test etmek için bu yapılandırma işe yaramaz. Bunun nedeni, "editor"un yalnızca dizenin bir bölümünü oluşturmasıdır.

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

Ancak şu yapı çalışır:

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

Bu işe yarar çünkü kelime sonlarını ve dizedeki .* önek ve sonekine sahip diğer tüm bölümleri dikkate alır.

Bu örnekte, Matches operatörüyle "editor" için de test yapabilirsiniz:

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

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

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

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