फ़्लो वैरिएबल के साथ शर्तें

आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी

शर्त के आधार पर काम करने वाले स्टेटमेंट, सभी प्रोग्रामिंग भाषाओं में कंट्रोल स्ट्रक्चर होते हैं. प्रोग्रामिंग भाषा की तरह, एपीआई प्रॉक्सी कॉन्फ़िगरेशन में फ़्लो, नीतियां, चरण, और RouteRule के लिए शर्त वाले स्टेटमेंट इस्तेमाल किए जा सकते हैं. शर्तों के आधार पर स्टेटमेंट तय करके, अपनी एपीआई के लिए डाइनैमिक व्यवहार तय किया जा सकता है. डाइनैमिक व्यवहार की मदद से, कई काम किए जा सकते हैं. जैसे, सिर्फ़ मोबाइल डिवाइसों के लिए एक्सएमएल को JSON में बदलना या अनुरोध के मैसेज के कॉन्टेंट टाइप या एचटीटीपी वर्ब के आधार पर, बैकएंड यूआरएल पर रूट करना.

इस विषय में, शर्तों का इस्तेमाल करके एपीआई मैनेजमेंट की सुविधाओं को रनटाइम पर डाइनैमिक तरीके से लागू करने का तरीका बताया गया है. इसके लिए, आपको कोई कोड लिखने की ज़रूरत नहीं है.

शर्तों के आधार पर स्टेटमेंट कॉन्फ़िगर करना

एपीआई प्रॉक्सी में शर्त के हिसाब से काम करने की सुविधा लागू करने के लिए, शर्तों और वैरिएबल के कॉम्बिनेशन का इस्तेमाल किया जाता है. कंडिशनल स्टेटमेंट, Condition एलिमेंट का इस्तेमाल करके बनाया जाता है. यहां खाली शर्त का उदाहरण दिया गया है:

<Condition></Condition>

कंडीशनल स्टेटमेंट बनाने के लिए, कंडीशनल ऑपरेटर और वैरिएबल जोड़ें. इससे यह स्ट्रक्चर बनता है:

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

शर्त के साथ इस्तेमाल किए जा सकने वाले ऑपरेटर में ये शामिल हैं: = (बराबर है), != (बराबर नहीं है), और > (इससे ज़्यादा है). पढ़ने में आसानी के लिए, शर्तों को इस तरह भी लिखा जा सकता है टेक्स्ट: equals, notequals, greaterthan.

यूआरआई पाथ के साथ काम करते समय, ~/ या MatchesPath का इस्तेमाल किया जा सकता है. आपके पास ~~ ऑपरेटर का इस्तेमाल करके, JavaRegex रेगुलर एक्सप्रेशन का मिलान करने का विकल्प भी है.

शर्तों का इस्तेमाल, बैकएंड एपीआई संसाधनों के लिए एपीआई प्रॉक्सी के कंडीशनल फ़्लो को तय करने के लिए किया जाता है. इसके बारे में बैकएंड एपीआई संसाधनों के लिए कंडीशनल फ़्लो बनाना में बताया गया है. शर्तों की पूरी सूची देखने के लिए, शर्तों का रेफ़रंस देखें.

वैरिएबल

शर्तें, वैरिएबल की वैल्यू का आकलन करके काम करती हैं. वैरिएबल, एपीआई प्रॉक्सी के ज़रिए किए गए एचटीटीपी लेन-देन की प्रॉपर्टी होती है. इसके अलावा, यह एपीआई प्रॉक्सी कॉन्फ़िगरेशन की प्रॉपर्टी भी होती है. जब भी किसी एपीआई प्रॉक्सी को किसी ऐप्लिकेशन से अनुरोध मिलता है, तो Apigee Edge, सिस्टम टाइम, ऐप्लिकेशन के नेटवर्क की जानकारी, मैसेज पर मौजूद एचटीटीपी हेडर, एपीआई प्रॉक्सी कॉन्फ़िगरेशन, नीति लागू करने की प्रोसेस वगैरह से जुड़े वैरिएबल की लंबी सूची भरता है. इससे एक ऐसा कॉन्टेक्स्ट तैयार होता है जिसका इस्तेमाल, कंडीशनल स्टेटमेंट सेट अप करने के लिए किया जा सकता है.

वैरिएबल में हमेशा डॉटेड नोटेशन का इस्तेमाल किया जाता है. उदाहरण के लिए, अनुरोध के मैसेज में मौजूद एचटीटीपी हेडर, request.header.{header_name} नाम के वैरिएबल के तौर पर उपलब्ध होते हैं. इसलिए, Content-type हेडर का आकलन करने के लिए, request.header.Content-type वैरिएबल का इस्तेमाल किया जा सकता है. उदाहरण के लिए, request.header.Content-type = "application/json" से पता चलता है कि अनुरोध का कॉन्टेंट टाइप JSON होना चाहिए.

मान लें कि आपको एक ऐसी शर्त बनानी है जिसकी वजह से नीति सिर्फ़ तब लागू हो, जब अनुरोध मैसेज GET हो. अनुरोध के एचटीटीपी वर्ब का आकलन करने वाली शर्त बनाने के लिए, यहां दिया गया कंडीशनल स्टेटमेंट बनाएं. इस शर्त में वैरिएबल की वैल्यू request.verb है. वैरिएबल की वैल्यू GET है. ऑपरेटर = है.

<Condition>request.verb = "GET"</Condition>
इनका भी इस्तेमाल किया जा सकता है: 
<Condition>request.verb equals "GET"</Condition>

Edge, शर्तों का आकलन करने के लिए इस तरह के स्टेटमेंट का इस्तेमाल करता है. अगर अनुरोध से जुड़ा एचटीटीपी वर्ब GET है, तो ऊपर दिया गया उदाहरण सही के तौर पर नतीजे दिखाता है. अगर अनुरोध से जुड़ा एचटीटीपी वर्ब, POST है, तो स्टेटमेंट का आकलन गलत के तौर पर किया जाता है.

डाइनैमिक व्यवहार को चालू करने के लिए, फ़्लो, चरणों, और RouteRules में शर्तें जोड़ी जा सकती हैं.

किसी फ़्लो में शर्त जोड़ने पर, 'शर्त के साथ फ़्लो' बनता है. शर्त के हिसाब से काम करने वाले फ़्लो सिर्फ़ तब काम करते हैं, जब शर्त पूरी होती है. किसी शर्त वाले फ़्लो में जितनी चाहें उतनी नीतियां अटैच की जा सकती हैं. शर्त के साथ फ़्लो का इस्तेमाल करके, अनुरोध या जवाब के उन मैसेज के लिए प्रोसेसिंग के खास नियम बनाए जा सकते हैं जो कुछ शर्तों को पूरा करते हैं.

उदाहरण के लिए, ऐसा फ़्लो बनाने के लिए जो सिर्फ़ तब काम करे, जब अनुरोध वर्ब GET हो:

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

GET अनुरोधों के लिए एक फ़्लो और POST अनुरोधों के लिए दूसरा फ़्लो बनाने के लिए:

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

नीचे दिए गए उदाहरण में दिखाया गया है कि नीति के चरण पर ही शर्त लागू की जा सकती है. नीचे दी गई शर्त की वजह से, VerifyApiKey नीति सिर्फ़ तब लागू होती है, जब अनुरोध मैसेज POST हो.

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

इस तरह के शर्त वाले फ़्लो तय करने के बाद, उनमें नीतियां जोड़ी जा सकती हैं. इससे एपीआई प्रॉक्सी, GET अनुरोधों के लिए नीतियों का एक सेट और POST अनुरोधों के लिए नीतियों का दूसरा सेट लागू कर सकती है.

रेफ़रंस के बारे में पूरी जानकारी के लिए, यहां दिए गए संसाधन देखें:

उदाहरण 1

यहां दिए गए उदाहरण में, Convert-for-devices नाम का एक शर्त वाला फ़्लो दिखाया गया है. इसे ProxyEndpoint के रिस्पॉन्स फ़्लो में कॉन्फ़िगर किया गया है. शर्त को उस इकाई में एक एलिमेंट के तौर पर जोड़ें जिस पर शर्त लागू होती है. इस उदाहरण में, शर्त फ़्लो का एक कॉम्पोनेंट है. इसलिए, स्टेटमेंट के सही होने पर फ़्लो को लागू किया जाएगा.

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

किसी ऐप्लिकेशन से मिले हर अनुरोध के लिए, Edge, वैरिएबल के तौर पर मौजूद सभी एचटीटीपी हेडर की वैल्यू सेव करता है. अगर अनुरोध में User-Agent नाम का कोई एचटीटीपी हेडर शामिल है, तो उस हेडर और उसकी वैल्यू को request.header.User-Agent नाम के वैरिएबल के तौर पर सेव किया जाता है.

ऊपर दिए गए ProxyEndpoint कॉन्फ़िगरेशन के हिसाब से, Edge request.header.User-Agent वैरिएबल की वैल्यू की जांच करता है. इससे यह पता चलता है कि शर्त सही है या नहीं.

अगर शर्त सही है, यानी कि वैरिएबल की वैल्यू request.header.User-Agent, Mozilla के बराबर है, तो शर्त के साथ फ़्लो लागू होता है. साथ ही, ConvertToJSON नाम की XMLtoJSON नीति लागू होती है. अगर ऐसा नहीं होता है, तो Flow को लागू नहीं किया जाता है. साथ ही, अनुरोध करने वाले ऐप्लिकेशन को एक्सएमएल फ़ॉर्मैट में, बिना बदलाव किया गया एक्सएमएल जवाब भेजा जाता है.

उदाहरण 2

आइए, एक उदाहरण का इस्तेमाल करते हैं. इसमें आपको जवाब के मैसेज को एक्सएमएल से JSON में बदलना है. हालांकि, यह बदलाव सिर्फ़ मोबाइल डिवाइसों के लिए करना है. सबसे पहले, ऐसी नीति बनाएं जो Weather API से मिले XML फ़ॉर्मैट वाले जवाब को JSON में बदल दे:

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

ऊपर दिए गए नीति के कॉन्फ़िगरेशन से, एपीआई प्रॉक्सी को यह निर्देश मिलता है कि वह जवाब का मैसेज ले, डिफ़ॉल्ट सेटिंग के साथ XML से JSON में कन्वर्ज़न करे, और फिर नतीजे को नए जवाब के मैसेज में लिखे. (अगर आपको एक्सएमएल से JSON में अनुरोध मैसेज को बदलना है, तो इन दोनों वैल्यू को request पर सेट करें.)

देखें

आपको एक्सएमएल से JSON में रिस्पॉन्स बदलने हैं. इसलिए, आपको कन्वर्ज़न करने के लिए, शर्त के साथ रिस्पॉन्स देने वाला फ़्लो कॉन्फ़िगर करना होगा. उदाहरण के लिए, क्लाइंट ऐप्लिकेशन को जवाब भेजने से पहले, सभी जवाबों को XML से JSON में बदलने के लिए, ProxyEndpoint के जवाब वाले फ़्लो को इस तरह कॉन्फ़िगर करें.

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

स्टैंडर्ड अनुरोध का इस्तेमाल करके एपीआई को चालू करने पर, जवाब को JSON फ़ॉर्मैट में फ़ॉर्मैट किया जाता है.

हालांकि, आपका लक्ष्य सिर्फ़ मौसम की रिपोर्ट को JSON में बदलना है. ऐसा तब करना है, जब अनुरोध करने वाला क्लाइंट कोई मोबाइल डिवाइस हो. इस तरह के डाइनैमिक व्यवहार को चालू करने के लिए, आपको फ़्लो में एक शर्त वाला स्टेटमेंट जोड़ना होगा.

कंडिशनल फ़्लो की जांच करना

इस सैंपल अनुरोध में, एचटीटीपी User-Agent हेडर को Mozilla पर सेट किया गया है. इससे शर्त वाले स्टेटमेंट का आकलन 'सही' के तौर पर होता है और शर्त वाला फ़्लो Convert-for-devices एक्ज़ीक्यूट होता है.

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

इसके अलावा, Python की सुविधा वाले प्लैटफ़ॉर्म पर बेहतर तरीके से प्रिंट करने के लिए:

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

जवाब का उदाहरण:

. . .

"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 हेडर के बिना सबमिट की गई या Mozilla से अलग वैल्यू वाली किसी भी अनुरोध के लिए, एक्सएमएल फ़ॉर्मैट में जवाब मिलेगा.

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

बदलाव किए बिना एक्सएमएल फ़ाइल का जवाब दिया जाता है.

जवाब का उदाहरण:

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

पैटर्न मैचिंग

इस सेक्शन में, Apigee फ़्लो में शर्तों के साथ पैटर्न मैचिंग का इस्तेमाल करने का तरीका बताया गया है.

ऑपरेटर

इस सेक्शन में, शर्त के साथ इस्तेमाल किए जाने वाले स्टेटमेंट में, पैटर्न मैचिंग वाले इन ऑपरेटर का इस्तेमाल करने का तरीका बताया गया है:

मैच

सबसे पहले, "मैच" या "~" कंडीशनल ऑपरेटर के बारे में जानते हैं. ये दोनों ऑपरेटर एक ही हैं. अंग्रेज़ी वर्शन, "Matches" को ज़्यादा आसानी से पढ़ा जा सकता है.

खास जानकारी: "Matches" ऑपरेटर से आपको दो विकल्प मिलते हैं. स्ट्रिंग से हूबहू मिलान करें या "*" का इस्तेमाल करके वाइल्डकार्ड मैच करें. जैसा कि आपको पता होगा, वाइल्डकार्ड शून्य या उससे ज़्यादा वर्णों से मेल खाता है. आइए, देखते हैं कि यह सुविधा कैसे काम करती है.

यहां दिए गए एक्सएमएल में, चरण की शर्त दिखाई गई है. शर्त के सही होने पर, यह SomePolicy नीति को लागू करता है. इस उदाहरण में, हम proxy.pathsuffix वैरिएबल की जांच करते हैं. यह Edge में मौजूद एक बिल्ट-इन वैरिएबल है. यह अनुरोध के पाथ सफ़िक्स को सेव करता है. हालांकि, ध्यान दें कि स्ट्रिंग वाले किसी भी फ़्लो वैरिएबल की वैल्यू को टेस्ट किया जा सकता है. इसलिए, इस मामले में अगर आने वाले अनुरोध का बेस पाथ /animals है और अनुरोध /animals/cat है, तो पाथ सफ़िक्स, लिटरल स्ट्रिंग "/cat" है.

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

सवाल: कौनसा प्रॉक्सी पाथ सफ़िक्स, SomePolicy को लागू करेगा? सिर्फ़ एक ही संभावना है.

एपीआई कॉल:

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

क्या नीति लागू होती है? हां, क्योंकि प्रॉक्सी पाथ का सफ़िक्स, "/cat" से पूरी तरह मेल खाता है. अगर सफ़िक्स /bat या /dog या "/" या कुछ और है, तो यह लागू नहीं होगा.

अब इस शर्त वाले स्टेटमेंट पर विचार करें, जिसमें हमने वाइल्डकार्ड वर्ण "*" का इस्तेमाल किया है:

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

एपीआई कॉल:

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

क्या नीति लागू होती है? हां, क्योंकि वाइल्डकार्ड किसी भी वर्ण से मेल खाता है. साथ ही, "/cat" एक मैच है.

एपीआई कॉल:

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

क्या नीति लागू होती है? हां, क्योंकि वाइल्डकार्ड किसी भी वर्ण से मेल खाता है. इसलिए, "/bat" एक मैच है.

एपीआई कॉल:

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

क्या नीति लागू होती है? बिलकुल नहीं -- हालांकि, वाइल्डकार्ड "o" से मेल खाता है, लेकिन अक्षर "wl" मेल नहीं खाते.

अब वाइल्डकार्ड को प्रत्यय के आखिर में ले जाएं:

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

एपीआई कॉल:

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

क्या नीति लागू होती है? हां, क्योंकि वाइल्डकार्ड किसी भी वर्ण के शून्य या उससे ज़्यादा बार आने पर मैच करता है.

एपीआई कॉल:

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

क्या नीति लागू होती है? नहीं, "/bat" से कोई नतीजा नहीं मिला.

एपीआई कॉल:

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

क्या नीति लागू होती है? हां, वाइल्डकार्ड किसी भी वर्ण के शून्य या उससे ज़्यादा वर्णों से मेल खाता है. इसलिए, "123" से मेल खाने वाला नतीजा मिलता है.

एपीआई कॉल:

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

क्या नीति लागू होती है? हां, क्योंकि वाइल्डकार्ड किसी भी वर्ण के शून्य या उससे ज़्यादा वर्णों से मेल खाता है. इसलिए, "/bird/mouse" से मेल खाने वाला वर्ण मिलता है. ध्यान दें कि इस तरह के एक्सप्रेशन से आपको परेशानी हो सकती है, क्योंकि यह लिटरल वर्णों के बाद की हर चीज़ से मेल खाता है!

सवाल: क्या 'मिलान करता है' ऑपरेटर केस-सेंसिटिव होता है?

हां. मान लें कि आपके पास इस तरह की कोई शर्त है:

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

एपीआई कॉल:

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

क्या नीति लागू होती है? नहीं, वाइल्डकार्ड किसी भी अक्षर से मेल खाता है, भले ही वह अक्षर कैपिटल लेटर में हो या स्मॉल लेटर में. हालांकि, स्मॉल लेटर वाला "a", कैपिटल लेटर वाले "A" से मेल नहीं खाता.

एपीआई कॉल:

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

क्या नीति लागू होती है? हां, केस मैच करता है.

सवाल: Matches ऑपरेटर का इस्तेमाल करके, वर्णों को कैसे एस्केप किया जाता है?

आरक्षित वर्णों से बचने के लिए, प्रतिशत "%" वर्ण का इस्तेमाल करें. उदाहरण के लिए:

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

एपीआई कॉल:

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

क्या नीति लागू होती है? नहीं, Matches ऑपरेटर, "c*at" स्ट्रिंग को खोज रहा है.

एपीआई कॉल:

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

सवाल:क्या नीति लागू होती है?

हां, यह पाथ थोड़ा अलग है, लेकिन इससे मैच करता है.

JavaRegex

जैसा कि आपने देखा, "Matches" ऑपरेटर का इस्तेमाल सामान्य स्थितियों में किया जा सकता है. हालांकि, "JavaRegex" या "~~" ऑपरेटर का इस्तेमाल किया जा सकता है. ये दोनों एक ही ऑपरेटर हैं. हालांकि, JavaRegex को ज़्यादा आसानी से पढ़ा जा सकता है. इसे JavaRegex कहा जाता है, क्योंकि यह रेगुलर एक्सप्रेशन पैटर्न मैचिंग की सुविधा देता है. साथ ही, Edge, Java भाषा में java.util.regex पैकेज की क्लास के नियमों का पालन करता है. JavaRegex ऑपरेटर के काम करने का तरीका, Matches ऑपरेटर से बहुत अलग है. इसलिए, दोनों को एक जैसा न समझें!

खास जानकारी: "JavaRegex" ऑपरेटर की मदद से, शर्त वाले स्टेटमेंट में रेगुलर एक्सप्रेशन सिंटैक्स का इस्तेमाल किया जा सकता है.

नीचे दिए गए कोड में, चरण की शर्त दिखाई गई है. अगर शर्त सही होती है, तो यह SomePolicy नीति को लागू करता है. इस उदाहरण में, हम proxy.pathsuffix वैरिएबल की जांच करते हैं. यह Edge में पहले से मौजूद वैरिएबल है. यह अनुरोध के पाथ सफ़िक्स को सेव करता है. अगर आने वाले अनुरोध का बेस पाथ /animals है और अनुरोध /animals/cat है, तो पाथ सफ़िक्स, लिटरल स्ट्रिंग "/cat" होगा.

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

सवाल: कौनसा प्रॉक्सी पाथ सफ़िक्स, SomePolicy को लागू करेगा? Matches ऑपरेटर की तरह ही, इस मामले में भी सिर्फ़ एक संभावना है.

एपीआई कॉल:

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

क्या नीति लागू होती है? हां, क्योंकि प्रॉक्सी पाथ का सफ़िक्स, "/cat" से पूरी तरह मेल खाता है. अगर सफ़िक्स /bat या /dog या कोई और वैल्यू है, तो यह फ़ंक्शन काम नहीं करेगा.

अब, "*" क्वांटीफ़ायर का इस्तेमाल करके एक रेगुलर एक्सप्रेशन बनाते हैं. यह क्वांटीफ़ायर, पिछले वर्ण के शून्य या उससे ज़्यादा बार आने पर मैच करता है.

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

एपीआई कॉल:

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

क्या नीति लागू होती है? नहीं! "*" क्वांटीफ़ायर, पहले वर्ण के शून्य या उससे ज़्यादा बार आने पर मैच करता है. यह "c" है.

एपीआई कॉल:

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

क्या नीति लागू होती है? हां, क्योंकि वाइल्डकार्ड, पिछले वर्ण के शून्य या उससे ज़्यादा बार आने पर मैच करता है.

इसके बाद, हम "?" क्वांटीफ़ायर का इस्तेमाल करते हैं. यह पिछले वर्ण से एक बार या किसी भी बार मैच करता है.

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

एपीआई कॉल:

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

क्या नीति लागू होती है? हां. "?" क्वांटीफ़ायर, पहले मौजूद वर्ण के शून्य या एक बार आने पर मैच करता है. यह वर्ण "a" है.

एपीआई कॉल:

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

क्या नीति लागू होती है? हां. "?" क्वांटीफ़ायर, पिछले वर्ण से एक या कोई भी वर्ण मैच करता है. इस मामले में, "a" वर्ण मौजूद नहीं है. इसलिए, शर्त सही के तौर पर तय होती है.

एपीआई कॉल:

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

क्या नीति लागू होती है? नहीं. "?" क्वांटीफ़ायर, पहले मौजूद वर्ण के एक वर्ण से मैच करता है. इस मामले में, यह वर्ण "a" है.

इसके बाद, हम रेगुलर एक्सप्रेशन की "[abc]" या "ग्रुपिंग" स्टाइल का इस्तेमाल करते हैं. यह "a" या "b" या "c" वर्णों से मेल खाता है.

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

एपीआई कॉल:

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

क्या नीति लागू होती है? हां. यहां रेगुलर एक्सप्रेशन का इस्तेमाल किया जा रहा है. साथ ही, "[cbr]" एक्सप्रेशन, "c", "b" या "r" से मेल खाता है. ये कॉल भी मैच होते हैं:

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

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

हालांकि, यह मेल नहीं खाता:

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

सवाल: क्या JavaRegex ऑपरेटर में अंग्रेज़ी के छोटे और बड़े अक्षरों का अंतर होता है?

हां. मान लें कि आपके पास इस तरह की कोई शर्त है:

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

एपीआई कॉल:

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

क्या नीति लागू होती है? हां, रेगुलर एक्सप्रेशन, पिछले वर्ण के शून्य या एक वर्ण से मेल खाता है. यह वर्ण "a" है.

एपीआई कॉल:

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

सवाल: क्या नीति लागू होती है?

नहीं, क्योंकि कैपिटल "A", लोअरकेस "a" से मेल नहीं खाता.

MatchesPath

MatchesPath ऑपरेटर को "~/" के तौर पर भी तय किया जा सकता है. यह Matches (~) और JavaRegex (~~) ऑपरेटर की तरह दिखता है. हालांकि, MatchesPath पूरी तरह से अलग है.

बस यह याद रखें कि यह ऑपरेटर, पाथ को हिस्सों की सीरीज़ के तौर पर देखता है. इसलिए, अगर पाथ /animals/cats/wild है, तो पाथ को "/animals", "/cats", और "/wild" के तौर पर देखा जा सकता है.

MatchesPath ऑपरेटर की मदद से, दो वाइल्डकार्ड नोटेशन का इस्तेमाल किया जा सकता है: एक तारांकन (*) और दो तारांकन (**). एक तारांकन, पाथ के एक एलिमेंट से मेल खाता है. डबल ऐस्टरिक, एक या कई पाथ एलिमेंट से मैच करता है.

आइए एक उदाहरण देखें. इस उदाहरण में, हम proxy.pathsuffix वैरिएबल की जांच करते हैं. यह Edge में मौजूद एक बिल्ट-इन वैरिएबल है. यह अनुरोध के पाथ सफ़िक्स को सेव करता है. हालांकि, ध्यान दें कि स्ट्रिंग वाले किसी भी फ़्लो वैरिएबल की वैल्यू की जांच की जा सकती है.

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

सवाल: कौनसा प्रॉक्सी पाथ सफ़िक्स, SomePolicy को लागू करेगा?

एपीआई कॉल:

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

सवाल: क्या नीति लागू होती है?

नहीं, क्योंकि "/*" के मुताबिक, स्थिति के लिए "/animals" के बाद एक और पाथ एलिमेंट की ज़रूरत होती है.

एपीआई कॉल:

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

क्या नीति लागू होती है? हां, पाथ में एक और पाथ एलिमेंट है. यह "/animals/" के बाद वाला हिस्सा है, लेकिन यह खाली है.

एपीआई कॉल:

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

क्या नीति लागू होती है? हां, क्योंकि पाथ में साफ़ तौर पर एक ऐसा एलिमेंट ("/cats") मौजूद है जो "/animals" के बाद आता है

एपीआई कॉल:

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

सवाल: क्या नीति लागू होती है?

नहीं, क्योंकि एक स्टार सिर्फ़ एक पाथ एलिमेंट से मैच करता है. साथ ही, इस एपीआई में "/animals" के बाद एक से ज़्यादा एलिमेंट हैं.

अब डबल ऐस्टरिक का इस्तेमाल करते हैं:

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

सवाल: कौनसा प्रॉक्सी पाथ सफ़िक्स, SomePolicy को लागू करेगा?

एपीआई कॉल:

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

क्या नीति लागू होती है? नहीं, क्योंकि शर्त के लिए, "/**" से तय किया गया कम से कम एक पाथ एलिमेंट ज़रूरी है.

एपीआई कॉल:

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

क्या नीति लागू होती है?

हां, पाथ में एक और पाथ एलिमेंट है. यह "/animals/" के बाद वाला हिस्सा है, लेकिन यह खाली है.

एपीआई कॉल:

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

क्या नीति लागू होती है?

हां, क्योंकि पाथ में कम से कम एक ऐसा एलिमेंट है जो "/animals" के बाद आता है

एपीआई कॉल:

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

क्या नीति लागू होती है?

हां, क्योंकि पाथ में "/animals" के बाद एक से ज़्यादा एलिमेंट हैं

तारे के निशान को मिक्स करना

पाथ मैचिंग को और बेहतर बनाने के लिए, सिंगल (*) और डबल (**) तारे के चिह्न के कॉम्बिनेशन का इस्तेमाल किया जा सकता है.

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

एपीआई कॉल:

इन सभी एपीआई कॉल से मैच मिलेगा:

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

और

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

और

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

एपीआई रिसॉर्स

RESTful सेवाएं, एपीआई संसाधनों का कलेक्शन होती हैं. एपीआई रिसॉर्स, यूआरआई पाथ का एक फ़्रैगमेंट होता है. यह ऐसी इकाई की पहचान करता है जिसे डेवलपर, आपके एपीआई को कॉल करके ऐक्सेस कर सकते हैं. उदाहरण के लिए, अगर आपकी सेवा मौसम की रिपोर्ट और मौसम का पूर्वानुमान देती है, तो आपकी बैकएंड सेवा दो एपीआई संसाधन तय कर सकती है:

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

एपीआई प्रॉक्सी बनाते समय (जैसा कि अपनी पहली एपीआई प्रॉक्सी बनाएं में दिखाया गया है), कम से कम एक एलियास बेस यूआरएल बनाया जाता है. यह यूआरएल, आपकी बैकएंड सेवा से मैप होता है. उदाहरण के लिए:

बैकएंड का बेस यूआरएल नई/मिलती-जुलती एपीआई प्रॉक्सी का यूआरएल
http://mygreatweatherforecast.com http://{your_org}-{environment}.apigee.net/mygreatweatherforecast

इस समय, दोनों में से किसी भी बेस यूआरएल का इस्तेमाल करके, अपने बैकएंड पर एपीआई कॉल किए जा सकते हैं. हालांकि, एपीआई प्रॉक्सी यूआरएल का इस्तेमाल करने पर, आपको कुछ दिलचस्प जानकारी मिल सकती है.

एपीआई प्रॉक्सी का इस्तेमाल करने पर, Edge एपीआई के आंकड़े इकट्ठा करना शुरू कर देता है. इसके अलावा, प्रॉक्सी की मदद से, शर्तों के हिसाब से फ़्लो तय किए जा सकते हैं. ये फ़्लो, आपके बैकएंड के संसाधनों से मैप होते हैं. असल में, "अगर /reports रिसॉर्स को GET कॉल मिलता है, तो Edge को कुछ करना चाहिए."

इस इमेज में, दो ऐसे यूआरएल के व्यवहार में अंतर दिखाया गया है जो आखिर में एक ही बैकएंड को ऐक्सेस करते हैं. पहला, बिना प्रॉक्सी वाला संसाधन यूआरएल है. दूसरा, Edge API प्रॉक्सी है, जिसमें एक शर्त के साथ उसी बैकएंड संसाधन पर जाने का फ़्लो है. हम यहां शर्त के हिसाब से तय होने वाले फ़्लो के बारे में ज़्यादा जानकारी देंगे.

एपीआई प्रॉक्सी, बैकएंड के खास संसाधनों से कैसे मैप होती हैं

एपीआई प्रॉक्सी यूआरएल को बैकएंड सेवा के बेस यूआरएल पर मैप करके (प्रॉक्सी बनाते समय), कुछ संसाधनों में शर्त के साथ फ़्लो जोड़े जा सकते हैं. जैसे, पहले बताए गए /reports और /forecasts संसाधन.

मान लें कि आपको /reports या /forecasts रिसोर्स पर कॉल आने पर, Edge से "कोई कार्रवाई" करानी है. इस समय, Edge को यह नहीं बताया जा रहा है कि क्या करना है. सिर्फ़ यह बताया जा रहा है कि उसे उन संसाधनों के कॉल सुनने चाहिए. ऐसा शर्तों के साथ किया जाता है. Edge API प्रॉक्सी में, /reports और /forecasts के लिए शर्त के साथ फ़्लो बनाए जा सकते हैं. अवधारणा के तौर पर, यहां दिए गए एपीआई प्रॉक्सी एक्सएमएल से पता चलता है कि ये शर्तें कैसी दिख सकती हैं.

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

इन शर्तों में कहा गया है कि "जब यूआरएल में /reports और /forecasts के साथ GET अनुरोध आता है, तो Edge वही करेगा जो आपने (एपीआई डेवलपर) उसे बताया है. यह काम, उन फ़्लो से जुड़ी नीतियों के ज़रिए किया जाएगा जिन्हें आपने अटैच किया है.

यहां एक उदाहरण दिया गया है, जिसमें बताया गया है कि किसी शर्त के पूरा होने पर Edge को क्या करना चाहिए. नीचे दिए गए एपीआई प्रॉक्सी एक्सएमएल में, जब https://yourorg-test.apigee.net/mygreatweatherforecast/reports को GET अनुरोध भेजा जाता है, तो Edge जवाब में "XML-to-JSON-1" नीति लागू करता है.

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

शर्त के साथ लागू होने वाले फ़्लो के अलावा, हर एपीआई प्रॉक्सी में दो डिफ़ॉल्ट फ़्लो भी होते हैं: <PreFlow>, जो शर्त के साथ लागू होने वाले फ़्लो से पहले लागू होता है और <PostFlow>, जो शर्त के साथ लागू होने वाले फ़्लो के बाद लागू होता है. ये तब काम आते हैं, जब एपीआई प्रॉक्सी को कोई भी कॉल किया जाता है. उदाहरण के लिए, अगर आपको हर कॉल के साथ किसी ऐप्लिकेशन के एपीआई पासकोड की पुष्टि करनी है, भले ही बैकएंड रिसोर्स को ऐक्सेस किया जा रहा हो, तो <PreFlow> पर 'एपीआई पासकोड की पुष्टि करें' नीति लागू की जा सकती है. फ़्लो के बारे में ज़्यादा जानने के लिए, फ़्लो कॉन्फ़िगर करना लेख पढ़ें.

बैकएंड संसाधनों के लिए, शर्त के हिसाब से फ़्लो बनाना

एपीआई प्रॉक्सी में बैकएंड संसाधनों के लिए, शर्त के साथ काम करने वाले फ़्लो तय करना पूरी तरह से वैकल्पिक है. हालांकि, इन शर्तों के आधार पर तय किए गए फ़्लो से, आपको बेहतर तरीके से मैनेजमेंट और मॉनिटरिंग करने की सुविधा मिलती है.

आपके पास ये विकल्प होंगे:

  • मैनेजमेंट को इस तरह से लागू करें कि वह आपके एपीआई मॉडल के सिमैंटिक को दिखाए
  • अलग-अलग संसाधन पाथ (यूआरआई) पर नीतियां और स्क्रिप्ट वाला व्यवहार लागू करना
  • Analytics सेवाओं के लिए ज़्यादा सटीक मेट्रिक इकट्ठा करना

उदाहरण के लिए, मान लें कि आपको अपने बैकएंड /developers to /apps संसाधनों पर अलग-अलग तरह का लॉजिक लागू करना है.

इसके लिए, आपको अपनी एपीआई प्रॉक्सी में दो शर्तों वाले फ़्लो जोड़ने होंगे: /developers और /apps.

एपीआई प्रॉक्सी एडिटर के नेविगेटर पैन के डेवलप व्यू में, प्रॉक्सी एंडपॉइंट में डिफ़ॉल्ट के बगल में मौजूद, + आइकॉन पर क्लिक करें.

"नया शर्त के साथ काम करने वाला फ़्लो" विंडो में, आपको ये मुख्य कॉन्फ़िगरेशन डालने होंगे:

  • फ़्लो का नाम: डेवलपर
  • शर्त का टाइप: पाथ
  • पाथ: /developers

अगर यूआरआई के आखिर में /developers जोड़कर प्रॉक्सी को कॉल भेजा जाता है, तो शर्त ट्रिगर हो जाएगी और नीतियां लागू हो जाएंगी.

अब /apps के लिए, शर्त के साथ फ़्लो जोड़ें. मान लें कि आपको किसी अनुरोध में यूआरआई और POST वर्ब, दोनों पर शर्त ट्रिगर करनी है. कॉन्फ़िगरेशन में, ये सेटिंग शामिल हैं:

  • फ़्लो का नाम: ऐप्लिकेशन
  • शर्त का टाइप: पाथ और वर्ब
  • पाथ: /apps
  • क्रिया: POST

अगर यूआरआई के आखिर में /apps और POST वर्ब के साथ प्रॉक्सी को कॉल भेजा जाता है, तो शर्त ट्रिगर हो जाएगी और नीतियां लागू हो जाएंगी.

नेविगेटर पैनल में, आपको ऐप्लिकेशन और डेवलपर के लिए नए फ़्लो दिखेंगे.

एपीआई प्रॉक्सी एडिटर के कोड व्यू में, शर्त के हिसाब से तय किए गए फ़्लो का कॉन्फ़िगरेशन देखने के लिए, इनमें से कोई एक फ़्लो चुनें:

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

जैसा कि आप देख सकते हैं, एपीआई संसाधन सिर्फ़ शर्त के साथ काम करने वाले फ़्लो होते हैं. ये फ़्लो, आने वाले अनुरोध के यूआरआई पाथ का आकलन करते हैं. (proxy.pathsuffix वैरिएबल, उस अनुरोध के यूआरआई की पहचान करता है जो ProxyEndpoint कॉन्फ़िगरेशन में कॉन्फ़िगर किए गए BasePath के बाद आता है.)

आपके तय किए गए हर एपीआई संसाधन को, एपीआई प्रॉक्सी में शर्त के साथ लागू किया जाता है. (फ़्लो कॉन्फ़िगर करना लेख पढ़ें.)

एपीआई प्रॉक्सी को टेस्ट एनवायरमेंट में डिप्लॉय करने के बाद, यह अनुरोध:

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

इस वजह से, शर्त का आकलन 'सही है' के तौर पर किया जाएगा. साथ ही, इससे जुड़ा फ़्लो और इससे जुड़ी सभी नीतियां लागू होंगी.

यहां दी गई उदाहरण की शर्त में, Java रेगुलर एक्सप्रेशन का इस्तेमाल किया गया है. इससे /apps रिसोर्स को किए गए कॉल की पहचान की जा सकती है. इसमें आखिर में फ़ॉरवर्ड स्लैश (/apps या /apps/**) हो भी सकता है और नहीं भी हो सकता:

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

इस तरह की शर्त के बारे में ज़्यादा जानने के लिए, Apigee कम्यूनिटी में How to match regardless ... लेख पढ़ें.

हैरारकी वाले यूआरआई को मॉडल करना

कुछ मामलों में, आपके पास क्रमबद्ध एपीआई संसाधन होंगे. उदाहरण के लिए, Developer Services API, डेवलपर के सभी ऐप्लिकेशन की सूची बनाने का तरीका उपलब्ध कराता है. यूआरआई पाथ यह है:

/developers/{developer_email}/apps

आपके पास ऐसे संसाधन हो सकते हैं जिनमें किसी कलेक्शन में मौजूद हर इकाई के लिए एक यूनीक आईडी जनरेट किया जाता है. इसे कभी-कभी इस तरह एनोटेट किया जाता है:

/genus/:id/species

यह पाथ, इन दोनों यूआरआई पर एक जैसा लागू होता है:

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

एपीआई संसाधन में इस स्ट्रक्चर को दिखाने के लिए, वाइल्डकार्ड का इस्तेमाल किया जा सकता है. उदाहरण के लिए:

/developers/*/apps
 
/developers/*example.com/apps
 
/genus/*/species

इन क्रमबद्ध यूआरआई को एपीआई रिसॉर्स के तौर पर सही तरीके से हल करेगा.

कुछ मामलों में, खास तौर पर ज़्यादा लेवल वाले एपीआई के लिए, आपको किसी यूआरआई फ़्रैगमेंट के नीचे मौजूद सभी समस्याओं को हल करना पड़ सकता है. इसके लिए, अपने संसाधन की परिभाषा में डबल ऐस्टरिक वाइल्डकार्ड का इस्तेमाल करें. उदाहरण के लिए, अगर आपने यह एपीआई संसाधन तय किया है: 
/developers/**

वह एपीआई रिसॉर्स, इन यूआरआई पाथ को हल करेगा:

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

एपीआई प्रॉक्सी की परिभाषा में, शर्त के हिसाब से फ़्लो की शर्त इस तरह दिखेगी:

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

और उदाहरण

RouteRule से जुड़ी शर्त

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

किसी नीति से जुड़ी शर्त

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

कंडिशनल फ़्लो

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

शर्तों में ऑपरेटर के उदाहरण

यहां शर्तों को बनाने के लिए इस्तेमाल किए जाने वाले ऑपरेटर के कुछ उदाहरण दिए गए हैं:

  • 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

एक व्यावहारिक उदाहरण: पाथ के आखिर में मौजूद "/" को अनदेखा करें

Edge के डेवलपर आम तौर पर इन दोनों पाथ सफ़िक्स को हैंडल करना चाहते हैं: "/cat" और "/cat/". ऐसा इसलिए, क्योंकि कुछ उपयोगकर्ता या क्लाइंट, पाथ के आखिर में अतिरिक्त स्लैश के साथ आपके एपीआई को कॉल कर सकते हैं. ऐसे में, आपको अपने कंडीशनल स्टेटमेंट में इसे हैंडल करना होगा. इस इस्तेमाल के उदाहरण के बारे में, Apigee Community पर चर्चा की गई है.

अगर आपको रेगुलर एक्सप्रेशन का इस्तेमाल नहीं करना है, तो इस तरह से भी यह काम किया जा सकता है:

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

यह एक अच्छा विकल्प है. यह साफ़ हो और इसे पढ़ा जा सके.

हालांकि, रेगुलर एक्सप्रेशन का इस्तेमाल करके भी ऐसा किया जा सकता है. इसके लिए, यह तरीका अपनाएं. कोष्ठकों का इस्तेमाल, स्टेटमेंट के regex वाले हिस्से को ग्रुप करने के लिए किया जाता है. हालांकि, इनकी ज़रूरत नहीं होती.

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

एपीआई कॉल:

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

क्या नीति लागू होती है? हां. ध्यान दें कि रेगुलर एक्सप्रेशन में, "?" वर्ण का मतलब है: पिछले वर्ण का शून्य या एक मैच करें. इसलिए, "/cat" और "/cat/", दोनों मेल खाते हैं.

एपीआई कॉल:

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

क्या नीति लागू होती है? नहीं. रेगुलर एक्सप्रेशन, पिछले वर्ण के शून्य या सिर्फ़ एक बार आने पर मैच करता है. इसके अलावा, किसी और वर्ण का इस्तेमाल नहीं किया जा सकता.

JavaRegex की मदद से आर्बिट्रेरी स्ट्रिंग मैच करना

इस विषय में दिए गए सभी उदाहरणों में, हमने यह दिखाया है कि बिल्ट-इन फ़्लो वैरिएबल में से किसी एक को कैसे मैच किया जाता है: proxy.pathsuffix. यह जानना ज़रूरी है कि किसी भी स्ट्रिंग या फ़्लो वैरिएबल पर पैटर्न मैचिंग की जा सकती है. भले ही, वह प्रॉक्सी.पाथसफ़िक्स जैसे बिल्ट-इन फ़्लो वैरिएबल हो या न हो.

उदाहरण के लिए, अगर आपको किसी ऐसी शर्त की जांच करनी है जो किसी स्ट्रिंग की जांच करती है, तो मैचिंग ऑपरेटर का इस्तेमाल किया जा सकता है. यह स्ट्रिंग, बैकएंड पेलोड में दिखाई गई स्ट्रिंग या पुष्टि करने वाले सर्वर से मिली स्ट्रिंग हो सकती है. JavaRegex का इस्तेमाल करने पर, रेगुलर एक्सप्रेशन की तुलना पूरी सब्जेक्ट स्ट्रिंग से की जाएगी. अगर विषय "abc" है और रेगुलर एक्सप्रेशन "[a-z]" है, तो कोई मैच नहीं है, क्योंकि "[a-z]" सिर्फ़ एक अक्षर से मैच करता है. "[a-z]+" एक्सप्रेशन काम करता है. साथ ही, "[a-z]*" और "[a-z]{3}.

आइए, एक उदाहरण देखते हैं. मान लें कि ऑथेंटिकेशन सर्वर, भूमिकाओं की सूची को कॉमा लगाकर अलग की गई स्ट्रिंग के तौर पर दिखाता है: "editor, author, guest".

एडिटर की भूमिका की मौजूदगी की जांच करने के लिए, यह कंस्ट्रक्शन काम नहीं करेगा. ऐसा इसलिए, क्योंकि "एडिटर" सिर्फ़ पूरी स्ट्रिंग का हिस्सा है.

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

हालांकि, इस तरह से कंस्ट्रक्शन काम करेगा:

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

यह इसलिए काम करता है, क्योंकि यह शब्द के ब्रेक और स्ट्रिंग के किसी भी अन्य हिस्से को ध्यान में रखता है. साथ ही, इसमें .* प्रीफ़िक्स और सफ़िक्स होता है.

इस उदाहरण में, Matches ऑपरेटर का इस्तेमाल करके "editor" के लिए भी टेस्ट किया जा सकता है:

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

हालांकि, अगर आपको ज़्यादा सटीक जानकारी चाहिए, तो JavaRegex एक बेहतर विकल्प है.

JavaRegex एक्सप्रेशन में डबल कोट से बचना

कंडीशन सिंटैक्स के लिए, JavaRegex एक्सप्रेशन को डबल कोट में रैप करना ज़रूरी है. इसलिए, अगर आपके पास ऐसा Regex एक्सप्रेशन है जिसमें डबल कोट शामिल हैं, तो आपको उनसे मैच करने के लिए किसी दूसरे तरीके का इस्तेमाल करना होगा. इसका जवाब है यूनिकोड. उदाहरण के लिए, मान लें कि आपने ऐसा हेडर पास किया है जिसमें डबल कोट शामिल हैं. जैसे: 
 -H 'content-type:multipart/related; type="application/xop+xml"'
 अगर Regex की शर्त में उस हेडर को मैच करने की कोशिश की जाती है, तो आपको 'शर्त अमान्य है' गड़बड़ी का मैसेज मिलेगा. ऐसा इसलिए, क्योंकि एक्सप्रेशन में डबल कोट शामिल हैं: 
request.header.Content-Type ~~ "(multipart\/related)(; *type="application\/xop\+xml\")"
 इसका समाधान यह है कि ASCII पर आधारित डबल कोट को उनके यूनिकोड के बराबर, \u0022 से बदल दिया जाए. उदाहरण के लिए, यह एक्सप्रेशन मान्य है और इससे उम्मीद के मुताबिक नतीजा मिलता है: 
request.header.Content-Type ~~ "(multipart\/related)(; *type=\u0022application\/xop\+xml\u0022)"