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

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

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

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

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

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

<Condition></Condition>

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

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

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

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

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

वैरिएबल

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

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

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

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

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

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

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

उदाहरण 1

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

<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 फ़्लो में शर्तों के साथ पैटर्न मैचिंग का इस्तेमाल करने का तरीका बताया गया है.

ऑपरेटर

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

मैच

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

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

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

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

सवाल: किस प्रॉक्सी पाथ सफ़िक्स की मदद से, somePolicy को लागू किया जा सकेगा? इसके लिए, सिर्फ़ एक विकल्प है.

एपीआई कॉल:

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

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

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

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

एपीआई कॉल:

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

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

एपीआई कॉल:

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

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

एपीआई कॉल:

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

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

अब, वाइल्डकार्ड को सफ़िक्स के आखिर में ले जाएं:

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

एपीआई कॉल:

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

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

एपीआई कॉल:

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

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

एपीआई कॉल:

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

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

एपीआई कॉल:

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

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

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

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

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

एपीआई कॉल:

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

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

एपीआई कॉल:

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

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

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

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

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

एपीआई कॉल:

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

क्या नीति लागू होती है? नहीं, मैच ऑपरेटर, लिटरल स्ट्रिंग "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 लागू होगी? मैच ऑपरेटर की तरह ही, इस मामले में भी सिर्फ़ एक संभावना है.

एपीआई कॉल:

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

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

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

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

एपीआई कॉल:

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

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

एपीआई कॉल:

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

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

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

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

एपीआई कॉल:

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

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

एपीआई कॉल:

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

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

एपीआई कॉल:

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

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

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

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

एपीआई कॉल:

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

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

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

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

हालांकि, यह मैच नहीं है:

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

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

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

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

एपीआई कॉल:

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

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

एपीआई कॉल:

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

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

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

MatchesPath

MatchesPath ऑपरेटर को "~/" के तौर पर भी दिखाया जा सकता है. यह Matches (~) और JavaRegex (~~) ऑपरेटर से थोड़ा मिलता-जुलता है. लेकिन MatchesPath पूरी तरह से अलग है.

बस याद रखें कि यह ऑपरेटर पाथ को कई भागों के रूप में देखता है. इसलिए, अगर पाथ यह है: /animals/cats/wild, तो पाथ को "/animals", "/cats", और "/wild" से बना माना जा सकता है.

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

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

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

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

एपीआई कॉल:

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

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

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

एपीआई कॉल:

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

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

एपीआई कॉल:

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

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

एपीआई कॉल:

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

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

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

आइए, अब दो तारे के निशान का इस्तेमाल करें:

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

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

एपीआई कॉल:

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

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

एपीआई कॉल:

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

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

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

एपीआई कॉल:

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

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

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

एपीआई कॉल:

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

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

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

मिले-जुले तारे के निशान

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

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

एपीआई कॉल:

इन सभी एपीआई कॉल से मैच जनरेट होगा:

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

और


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Navigator पैनल में, आपको Apps और डेवलपर.

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

<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 कम्यूनिटी में बिना अनुमति के मैच करने का तरीका ... देखें.

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

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

/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/". ऐसा इसलिए है, क्योंकि कुछ उपयोगकर्ता या क्लाइंट, पाथ के आखिर में अतिरिक्त स्लैश के साथ आपके एपीआई को कॉल कर सकते हैं. इसलिए, आपको अपने कंडीशनल stmt में इसे हैंडल करना होगा. इस्तेमाल का यह सटीक उदाहरण पर है, 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 की मदद से आर्बिट्रेरी स्ट्रिंग को मैच करना

इस विषय के सभी उदाहरणों में, हम पहले से मौजूद फ़्लो वैरिएबल में से किसी एक से मैच करने का तरीका दिखाते हैं: proxy.pathsuffix. यह जानना अच्छा है कि किसी भी स्ट्रिंग या फ़्लो वैरिएबल पर पैटर्न मैचिंग की जा सकती है. भले ही, वह proxy.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>

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

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

<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\")"
इस समस्या को हल करने के लिए, ASCII पर आधारित डबल कोट को उनके यूनिकोड के बराबर, \u0022 से बदलें. उदाहरण के लिए, यह एक्सप्रेशन मान्य है और इससे उम्मीद के मुताबिक नतीजा मिलता है: 
request.header.Content-Type ~~ "(multipart\/related)(; *type=\u0022application\/xop\+xml\u0022)"