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

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

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

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

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

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

<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 का इस्तेमाल करते हैं, तो स्टेटमेंट का मान गलत के तौर पर आ जाता है.

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

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

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

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

जीईटी के लिए एक फ़्लो और पीओएसटी के लिए दूसरा फ़्लो बनाने के लिए:

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

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

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

उदाहरण 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 फ़ॉर्मैट में फ़ॉर्मैट किया जाता है.

हालांकि, आपका लक्ष्य Weather रिपोर्ट को सिर्फ़ 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" को ज़्यादा पठनीय विकल्प माना जाता है.

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

नीचे दिया गया एक्सएमएल, चरण की स्थिति दिखाता है. शर्त लागू होने पर, यह 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.util.regex में दी गई क्लास की क्लास में हैं. पैकेज सबमिट किया जाता है. JavaRegex ऑपरेटर के काम करने का तरीका, ऑपरेटर से मेल खाता हो, इसलिए दोनों को भ्रमित न करें!

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

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

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

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

प्रॉक्सी को कॉल भेजे जाने पर, शर्त ट्रिगर होगी और नीतियां लागू की जाएंगी यूआरआई और पीओएसटी के आखिर में /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>

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

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

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

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

इन हैरारकी यूआरआई को एपीआई संसाधनों के तौर पर सही तरीके से रिज़ॉल्व करेगा.

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

एक उदाहरण: "/" को अनदेखा करें पूरी तरह कैसे पाथ का आखिरी हिस्सा

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