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

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

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

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

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

एपीआई प्रॉक्सी में शर्त के हिसाब से काम करने की सुविधा, शर्तों और वैरिएबल के कॉम्बिनेशन का इस्तेमाल करके लागू की जाती है. कंडिशनल स्टेटमेंट बनाने के लिए, 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 होना चाहिए.

मान लें कि आपको एक शर्त वाला स्टेटमेंट बनाना है, जिससे कोई नीति सिर्फ़ तब लागू होगी, जब अनुरोध वाला मैसेज 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>

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

ज़्यादा जानकारी के लिए, ये संसाधन देखें:

• Flow वैरिएबल का रेफ़रंस
• शर्तों के बारे में जानकारी

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

उदाहरण 2

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

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

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

आपको जवाबों को एक्सएमएल से JSON में बदलना है. इसलिए, आपको कन्वर्ज़न के लिए, शर्त के हिसाब से जवाब देने वाला फ़्लो कॉन्फ़िगर करना होगा. उदाहरण के लिए, क्लाइंट ऐप्लिकेशन को जवाब वापस करने से पहले, सभी जवाबों को एक्सएमएल से 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 ऑपरेटर: आसान पैटर्न मैचिंग
• JavaRegex ऑपरेटर: मैच करने पर बेहतर कंट्रोल
• MatchesPath ऑपरेटर: पाथ फ़्रैगमेंट मैचिंग

मैच

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

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

यहां दिए गए एक्सएमएल में, Step शर्त दिखाई गई है. शर्त के सही होने पर, यह 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" से मैच मिलता है. ध्यान दें कि इस तरह का एक्सप्रेशन आपको परेशानी में डाल सकता है, क्योंकि यह लिटरल वर्णों के बाद की हर चीज़ से मैच करता है!

सवाल: क्या Matches ऑपरेटर केस-सेंसिटिव है?

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

<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

जैसा कि आपने देखा, "मैच" ऑपरेटर आसान स्थितियों के लिए बहुत अच्छा है. हालांकि, "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

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

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

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

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

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

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

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

यहां एक उदाहरण दिया गया है, जिसमें Edge को बताया गया है कि कोई शर्त पूरी होने पर क्या करना है. नीचे दिए गए एपीआई प्रॉक्सी एक्सएमएल में, जब 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 सेवाओं के लिए बारीकी से मेट्रिक इकट्ठा करना

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

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

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

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

• फ़्लो का नाम: डेवलपर
• शर्त का टाइप: पाथ
• पाथ: /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 कम्यूनिटी में चर्चा की गई है.

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

    <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. यह जानना अच्छा है कि किसी भी आर्बिट्रेरी स्ट्रिंग या फ़्लो वैरिएबल पर पैटर्न मैचिंग की जा सकती है. भले ही, वह 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 ऑपरेटर की मदद से "एडिटर" की भी जांच की जा सकती है:

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

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

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

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

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

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