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

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

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

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

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

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

<Condition></Condition>

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

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

शर्त के साथ इस्तेमाल किए जा सकने वाले ऑपरेटर में ये शामिल हैं: = (बराबर है), != (बराबर नहीं है), और > (इससे ज़्यादा है). पढ़ने में आसानी के लिए, शर्तों को इस तरह भी लिखा जा सकता है text: 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 में बदलने, और फिर नतीजे को नए रिस्पॉन्स मैसेज में लिखने के लिए कहा जाता है. (अगर आपको XML से 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 ऑपरेटर: पैटर्न से मिलान करने की सुविधा
• JavaRegex ऑपरेटर: मैचिंग पर बेहतर कंट्रोल
• MatchesPath ऑपरेटर: पाथ फ़्रैगमेंट मैचिंग

मैच

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

सवाल: क्या 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

जैसा कि आप देख सकते हैं, "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

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

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

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

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

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

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

मान लें कि आपको Edge से /reports या /forecasts रिसोर्स पर कॉल आने पर "कुछ काम" करवाना है. इस समय, 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 को जीईटी अनुरोध भेजा जाता है, तो 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> पर Verify API Key नीति लागू की जा सकती है. फ़्लो के बारे में ज़्यादा जानने के लिए, फ़्लो कॉन्फ़िगर करना लेख पढ़ें.

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

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

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

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

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