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 isteği içerik türüne veya HTTP fiiline göre bir arka uç URL'sine yönlendirme mesajını alırsınız.

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.

Koşullu ifadeleri yapılandırma

Koşullu davranış, API proxy'lerinde koşulların bir kombinasyonu kullanılarak uygulanır. ve değişkenler için geçerlidir. Bir koşullu ifade, Koşul öğesi kullanılarak oluşturulur. Aşağıdakiler boş bir koşuldur:

<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). Okunabilirlik için koşulları şu şekilde de yazabilirsiniz: metin: equals, notequals, greaterthan.

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

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. Örneğin, koşulların tam listesi için Koşullara referans bölümüne bakın.

Değişkenler

Koşullar, işlerini değişkenlerin değerlerini değerlendirerek gerçekleştirir. Değişkenler API proxy'si tarafından yürütülen bir HTTP işleminin veya API proxy'sinin mülkü yapılandırmanın bir parçasıdır. Bir API proxy'si uygulamadan istek aldığında Apigee Edge bir sistem saati, uygulamanın ağı gibi şeylerle ilişkili değişkenlerin uzun listesi bilgileri, mesajlardaki HTTP üstbilgileri, API proxy yapılandırması, politika yürütmeleri vb. Bu, koşullu ifadeleri ayarlamak için kullanabileceğiniz zengin bir bağlam oluşturur.

Değişkenler her zaman noktalı bir 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, daha sonra ifade yanlış olarak değerlendirilir.

Dinamik davranışı etkinleştirmek için Akışlara, Adımlara ve RouteRules'a koşul 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. İstediğiniz sayıda politika ekleyebilirsiniz koşullu Akış örneğidir. Koşullu Akış, son derece özelleştirilmiş işleme kuralları oluşturabilmenizi sağlar. istek veya yanıt mesajları için de kullanılı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 ve 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. İlgili içeriği oluşturmak için kullanılan Aşağıdaki Koşul, VerifyApiKey Politikası'nın yalnızca istek mesajı YAYINLA.

<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 ekleyerek API'yi etkinleştirebilirsiniz. GET istekleri için bir politika grubunu ve POST için başka bir politika grubunu zorunlu kılmak amacıyla kullanılan proxy kabul edersiniz.

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

1. Örnek

Aşağıdaki örnekte Convert-for-devices adlı tek bir koşullu akış gösterilmektedir. ProxyEndpoint yanıt akışında yapılandırılır. Koşulu varlığa öğe olarak ekleyerek koşulun geçerli olduğu anlamına gelir. 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 adında bir HTTP üstbilgisi 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ünde bulundurulduğunda Edge, koşulun şu şekilde değerlendirilip değerlendirilmediğini görmek için request.header.User-Agent değişkeni doğru.

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 request mesajını XML'den JSON'a dönüştürüyorsanız bu değerleri request olarak ayarlayın.)

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

<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, Hava Durumu raporlarını JSON'a dönüştürmek, istenen istemci mobil cihaz. Bu tür dinamik davranışı etkinleştirmek için seçeceğiz.

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

ya da Python'un kullanılabildiği yerleri kolayca yazmak 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ışındaki koşullarla kalıp eşleştirmenin nasıl kullanılacağı açıklanmaktadır.

Operatörler

Bu bölümde, aşağıdaki kalıp eşleştirme operatörlerinin koşullu ifadeler:

Şununla eşleşiyor:

"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şmeler" operatörü size iki olasılık 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 belirli bir sorunu çözmek için bir dize içeren akış değişkeninin değeri. Bu durumda, gelen istek /animals şeklindedir ve istek /animals/cat ise yol son eki, "/cat" değişmez 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? 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. Sonek /bat veya /dog ya da "/" veya başka bir şey.

Ş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 geçerli mi? Evet, çünkü joker karakter herhangi bir karakterle eşleşir, "/bat" eşleşmedir.

API Çağrısı:

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

Politika geçerli mi? 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 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 geçerli mi? 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 çok tekrarıyla eşleşir. "/bird/mouse" bir eşleşme getirir. 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 geçerli mi? 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 geçerli mi? Hayır, Eşleşmeler operatörü düz dizeyi arıyor "c*at".

API çağrısı:

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

Soru:Bu politika uygulanır mı?

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 ifadeye izin verdiğinden JavaRegex kalıp eşleştirmesi yeterlidir. Edge, java.util.regex'deki sınıflarla aynı kuralları uygular. paketi'ni başka bir dille destekler. JavaRegex operatörünün çalışma şekli Operatör eşleşiyor, bu nedenle ikisini karıştırmamak önemlidir.

Özet: "JavaRegex" operatör, tablodaki normal ifade koşullu ifadelerdir.

Aşağıdaki kodda bir Adım koşulu gösterilmektedir. Koşul doğru olarak değerlendirilir. Bu örnekte, yerleşik bir öğe olan proxy.pathsuffix değişkenini test ediyoruz değişkeni kullanabilirsiniz. Eğer gelen istek /animals şeklindedir ve istek /animals/cat ise yol son eki, "/cat" değişmez 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? 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 geçerli mi? Evet, çünkü proxy yolu son eki "/cat" ile eşleşir tam olarak bunu sağlar. Sonek /bat veya /dog ya da herhangi bir değerse yürütülmez else.

Ş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 "*" miktar belirleyici, preceding character (bir "c") değeridir.

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 çok tekrarıyla eşleşir karakteriyle ayrılır.

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 bulunduğundan, koşul doğru olarak değerlendirilir.

API Çağrısı:

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

Politika geçerli mi? 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. Bu çağrılar da eşleşir:

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ı 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 geçerli mi? Evet, normal ifade sıfır veya bir önceki karakterden biriyle eşleşir. Bu da "a"dır.

API çağrısı:

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

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

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

MatchesPath

MatchesPath operatörü, şu şekilde de belirtilebilir: "~/". Görünüşe göre biraz Matches (~) ve JavaRegex (~~) operatörleri. 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 yolları, yolların "/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 bulunur.

Bunu bir örnek üzerinde inceleyelim. Bu örnekte, proxy.pathsuffix değişkenini test ediyoruz, Edge'de isteğin yol son ekini depolayan yerleşik bir değişken 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: Bu politika yürürlüğe giriyor mu?

Hayır, çünkü koşul için sonradan başka bir yol öğesi gerekiyor "/*" ile belirtildiği şekliyle "/animals".

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, koşul için en az bir takip eden yol öğesi gerekiyor "/**" ile belirtilmiş.

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 sonrasında gelen en az bir öğe var "/animals"

API Çağrısı:

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

Politika geçerli mi?

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ının koleksiyonlarıdı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

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 görürseniz 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 ucunuzdaki kaynaklarla eşlenen koşullu akışlar tanımlamanızı sağlar. 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. Şunu yapacaksınız: durumlarla karşılaşabilirsiniz. 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, "/reports ile bir GET isteği geldiğinde ve /forecasts eklerse Edge sizin (API geliştiricisi) istediğiniz her şeyi yapar, politikalarla uyumlu olmasını sağlayabilirsiniz.

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>

İsteğe bağlı bu koşullu akışların yanı sıra, her API proxy'si için akışlar: koşullu akışlarınızdan önce yürütülen bir <PreFlow> ve <PostFlow>, koşullu akışlarınızdan sonra yürütüldü. Bunlar çeşitli API proxy'sine herhangi bir çağrı yapıldığında politikaların uygulanmasına olanak tanı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ıtan bir şekilde uygulayın
  • Bağımsız kaynak yollarına (URI'ler) politikalar ve komut dosyası davranışları uygulayın
  • 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ına ekleyin.

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

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

"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

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

Ş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 Fiil
  • 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.

Gezinme bölmesinde Uygulamalar ve Geliştiriciler.

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 istek. (proxy.pathsuffix değişkeni, ProxyEndpoint yapılandırmasında yapılandırılan BasePath'dir.)

Tanımladığınız her API kaynağı, API proxy'sindeki koşullu Akış tarafından 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 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ınız olur. Örneğin, Geliştirici Hizmetleri API, bir geliştiriciye ait 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, bazen aşağıdaki gibi ek açıklamalar eklenebilir:

/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ı çözümler:

/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

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>

Koşul bir politikaya eklendi

<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

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: "/" işaretini yoksayın CANNOT TRANSLATE yolun sonu

Edge geliştiricileri genellikle şu yol son eklerinin ikisini de ele almak ister: "/cat" ve "/cat/". Bunun nedeni, bazı kullanıcıların veya istemcilerin API'nizi ekstra yolu eğik çizgiyle destekler ve bunu koşullu açıklamalarına dikkat edin. 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 geçerli mi? 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 geçerli mi? Hayır. Normal ifade eklenir, 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 birinin nasıl eşleştirileceği gösterilmektedir: 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" ise ve normal ifade "[a-z]" ise eşleşme yoktur, çünkü "[a-z]" tam olarak bir alfa karakteriyle eşleşir. İlgili içeriği oluşturmak için kullanılan "[a-z]+" ifadesi ve "[a-z]*" ve "[a-z]{3} ile çalışır.

Somut bir örneğe bakalım. Kimlik doğrulama sunucusunun, bir dizi rolü ve biçimi olduğu gibi 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 son eki.

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

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

Ancak, daha fazla hassasiyet gerektiren durumlarda JavaRegex genellikle daha iyi bir seçimdir.

JavaRegex ifadelerinde çıkış karakterli çift tırnak

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ğıdakiler gibi çift tırnak işareti içeren bir üstbilgi geçirdiğinizi varsayalım: 
 -H 'content-type:multipart/related; type="application/xop+xml"'
 Bu başlığı bir normal ifade koşulunda eşlemeye çalışırsanız "Geçersiz Koşul" hatası alırsınız. şunları içerir: 
request.header.Content-Type ~~ "(multipart\/related)(; *type="application\/xop\+xml\")"
 Çözüm, ASCII tabanlı çift tırnak işaretlerini Unicode'daki 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)"