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

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

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

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

कंडिशनल स्टेटमेंट कॉन्फ़िगर करना

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

<Condition></Condition>

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

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

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

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

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

वैरिएबल

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

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

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

<Condition>request.verb = "GET"</Condition>
आप इनका इस्तेमाल भी कर सकते हैं: 
<Condition>request.verb equals "GET"</Condition>

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

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

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

उदाहरण के लिए, ऐसा फ़्लो बनाना जो सिर्फ़ तब काम करता हो, जब अनुरोध की कार्रवाई 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>

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

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

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

पूरी जानकारी के लिए, नीचे दिए गए लेख पढ़ें:

उदाहरण 1

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

<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 नीति लागू की जाती है. अगर ऐसा नहीं होता है, तो फ़्लो लागू नहीं होता है और अनुरोध करने वाले ऐप्लिकेशन को एक्सएमएल रिस्पॉन्स, बिना किसी बदलाव के (एक्सएमएल फ़ॉर्मैट में) लौटाया जाता है.

उदाहरण 2

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

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

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

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

<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" को पढ़ने का बेहतर विकल्प माना जाता है.

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

नीचे दिया गया एक्सएमएल, स्टेप से जुड़ी शर्त दिखाता है. यह स्थिति के सही के तौर पर आकलन करने पर, कुछ नीति को लागू करती है. इस उदाहरण में, हम वैरिएबल 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>

सवाल: किस प्रॉक्सी पाथ सफ़िक्स की वजह से कुछ नीति लागू होगी? ऐसा करने की सिर्फ़ एक संभावना है.

एपीआई कॉल:

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

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

एपीआई कॉल:

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

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

हां, हालांकि, यह पाथ थोड़ा असामान्य है, लेकिन मेल खाता है.

JavaRegex

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

खास जानकारी: "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>

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

एपीआई कॉल:

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", OR "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>

सवाल: किस प्रॉक्सी पाथ सफ़िक्स की वजह से कुछ नीति लागू होगी?

एपीआई कॉल:

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>

सवाल: किस प्रॉक्सी पाथ सफ़िक्स की वजह से कुछ नीति लागू होगी?

एपीआई कॉल:

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

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

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

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

API प्रॉक्सी का इस्तेमाल करने पर Edge जो एपीआई इकट्ठा करना शुरू करता है उसके अलावा, प्रॉक्सी की मदद से आपको कंडिशनल फ़्लो भी तय करने की सुविधा मिलती है जो आपके बैकएंड पर मौजूद संसाधनों से मैप होती है. इसका मतलब है, "अगर कोई जीईटी कॉल /reports रिसॉर्स में आता है, तो 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 के साथ जीईटी अनुरोध आता है, तो एज आपके (एपीआई डेवलपर ने) जो भी कहा होगा वह उन फ़्लो के साथ जोड़ी गई नीतियों की मदद से करेगा.

अब इस उदाहरण में बताया गया है कि कोई शर्त पूरी होने पर क्या करें. यहां दिए गए एपीआई प्रॉक्सी एक्सएमएल में, जब https://yourorg-test.apigee.net/mygreatweatherforecast/reports को जीईटी अनुरोध भेजा जाता है, तो रिस्पॉन्स के तौर पर 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 सेवाओं के लिए सटीक मेट्रिक इकट्ठा करना

उदाहरण के लिए, मान लें कि आपको अपने बैकएंड /डेवलपर से लेकर /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>

जैसा कि देखा जा सकता है, एपीआई रिसॉर्स सिर्फ़ कंडिशनल फ़्लो हैं, जो इनबाउंड अनुरोध के यूआरआई पाथ का आकलन करते हैं. प्रॉक्सी.pathsuffix वैरिएबल, अनुरोध के उस यूआरआई की पहचान करता है जो प्रॉक्सीEndpoint कॉन्फ़िगरेशन में कॉन्फ़िगर किए गए 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 कम्यूनिटी में, मैच करने का तरीका ... देखें.

मॉडलिंग हैरारकी वाले यूआरआई

कुछ मामलों में, आपके पास हैरारकी वाले एपीआई संसाधन होंगे. उदाहरण के लिए, 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 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

उदाहरण के लिए: पाथ के आखिर में "/" को अनदेखा करें

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

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

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

यह एक अच्छा विकल्प है. यह साफ़ और पढ़ने में आसान है.

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

<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 के साथ आर्बिट्रेरी स्ट्रिंग मैच करना

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

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

आइए, एक ठोस उदाहरण देखें. मान लें कि पुष्टि करने वाला सर्वर, कॉमा से अलग की गई स्ट्रिंग के तौर पर भूमिकाओं की सूची दिखाता है: "एडिटर, लेखक, मेहमान".

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

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

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

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

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

इस उदाहरण में, मैच ऑपरेटर के साथ "एडिटर" की जांच भी की जा सकती है:

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

हालांकि, जिन मामलों में आपको ज़्यादा सटीक जानकारी की ज़रूरत होती है उनमें JavaRegex हमेशा बेहतर विकल्प होता है.

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

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