ফ্লো ভেরিয়েবল সহ কন্ডিশন

আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন-এ যান। info

কন্ডিশনাল স্টেটমেন্ট হল সব প্রোগ্রামিং ল্যাঙ্গুয়েজের একটি সাধারণ কন্ট্রোল স্ট্রাকচার। প্রোগ্রামিং ল্যাঙ্গুয়েজের মতো, API প্রক্সি কনফিগারেশন ফ্লো, নীতি, ধাপ ও রুটরুলের জন্য শর্তসাপেক্ষ স্টেটমেন্ট সমর্থন করে। শর্তসাপেক্ষ স্টেটমেন্ট সংজ্ঞায়িত করার মাধ্যমে, আপনি আপনার API-এর জন্য ডায়নামিক আচরণ সংজ্ঞায়িত করেন। এই ডাইনামিক আচরণের মাধ্যমে আপনি শুধু মোবাইল ডিভাইসের জন্য XML-কে JSON-এ কনভার্ট করা অথবা কন্টেন্টের ধরন বা অনুরোধ মেসেজের HTTP ভার্বের উপর ভিত্তি করে ব্যাকএন্ড URL-এ রাউট করার মতো কাজ করতে পারবেন।

এই বিষয়ে দেখানো হয়েছে যে কোনও কোড না লিখে রানটাইমে API ম্যানেজমেন্ট ফিচার ডায়নামিকভাবে প্রয়োগ করার জন্য কীভাবে শর্ত ব্যবহার করতে হয়।

শর্তসাপেক্ষ স্টেটমেন্ট কনফিগার করুন

শর্ত এবং ভেরিয়েবল-এর কম্বিনেশন ব্যবহার করে API প্রক্সিতে শর্তাধীন আচরণ প্রয়োগ করা হয়। শর্তসাপেক্ষ বিবৃতি, শর্ত এলিমেন্ট ব্যবহার করে তৈরি করা হয়। নিম্নলিখিত শর্তটি খালি:

<Condition></Condition>

শর্তসাপেক্ষ স্টেটমেন্ট তৈরি করতে, আপনি শর্তসাপেক্ষ অপারেটর এবং ভেরিয়েবল যোগ করে নিম্নলিখিত স্ট্রাকচার তৈরি করেন:

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

কাজ করে এমন শর্তসাপেক্ষ অপারেটরের মধ্যে = (সমান), != (সমান নয়) এবং > (এর চেয়ে বড়) অন্তর্ভুক্ত। পড়ার সুবিধার জন্য, আপনি শর্তগুলি এভাবেও লিখতে পারেন টেক্সট: equals, notequals, greaterthan।

URI পাথ নিয়ে কাজ করার সময় আপনি ~/ বা MatchesPath ব্যবহার করতে পারবেন। এছাড়াও, আপনি ~~ অপারেটর ব্যবহার করে JavaRegex রেগুলার এক্সপ্রেশন ম্যাচ করতে পারবেন।

ব্যাকএন্ড API রিসোর্সে API প্রক্সি কন্ডিশনাল ফ্লো নির্ধারণ করতে কন্ডিশন ব্যবহার করা হয়, যা ব্যাকএন্ড API রিসোর্সে কন্ডিশনাল ফ্লো তৈরি করুন লিঙ্কে বর্ণনা করা হয়েছে। শর্তের সম্পূর্ণ তালিকা দেখতে, শর্তের রেফারেন্স দেখুন।

ভেরিয়েবল

ভেরিয়েবেলের ভ্যালু মূল্যায়ন করে শর্ত কাজ করে। ভেরিয়েবেল হল API প্রক্সি দ্বারা এক্সিকিউট করা HTTP ট্রানজ্যাকশনের প্রপার্টি অথবা API প্রক্সি কনফিগারেশনের নিজস্ব প্রপার্টি। কোনও অ্যাপ থেকে API প্রক্সি অনুরোধ পেলেই, Apigee Edge সিস্টেমের সময়, অ্যাপের নেটওয়ার্ক সংক্রান্ত তথ্য, মেসেজে HTTP হেডার, API প্রক্সি কনফিগারেশন, নীতি প্রয়োগ করা এবং আরও অনেক কিছুর সাথে সম্পর্কিত ভেরিয়েবলের একটি দীর্ঘ তালিকা তৈরি করে। এটি একটি সমৃদ্ধ প্রসঙ্গ তৈরি করে যা আপনি শর্তসাপেক্ষ বিবৃতি সেট-আপ করতে ব্যবহার করতে পারেন।

ভেরিয়েবল সবসময় ডটেড নোটেশন ব্যবহার করে। যেমন, অনুরোধ মেসেজে HTTP হেডার request.header.{header_name} নামের ভেরিয়েবল হিসেবে উপলভ্য। তাই, Content-type হেডার মূল্যায়ন করতে, আপনি request.header.Content-type ভেরিয়েবেল ব্যবহার করতে পারেন। যেমন, request.header.Content-type = "application/json" থেকে বোঝা যায় যে অনুরোধের কন্টেন্টের ধরন JSON হতে হবে।

ধরুন, আপনাকে এমন একটি শর্তসাপেক্ষ স্টেটমেন্ট তৈরি করতে হবে যার ফলে কোনও নীতি তখনই এনফোর্স করা হবে যখন অনুরোধের মেসেজটি GET হবে। অনুরোধের HTTP ভার্ব মূল্যায়ন করে এমন শর্ত তৈরি করতে, আপনি নিচে শর্তাধীন বিবৃতি তৈরি করুন। এই কন্ডিশনে ভেরিয়েবেল হল request.verb। ভেরিয়েবেলটির মান হল GET। অপারেটর হল =।

<Condition>request.verb = "GET"</Condition>
আপনি এগুলিও ব্যবহার করতে পারেন: 
<Condition>request.verb equals "GET"</Condition>

Edge শর্ত মূল্যায়ন করতে এই ধরনের স্টেটমেন্ট ব্যবহার করে। অনুরোধের সাথে যুক্ত HTTP ভার্ব GET হলে, উপরের উদাহরণটি সত্য হিসেবে মূল্যায়ন করে। অনুরোধের সাথে যুক্ত HTTP ভার্ব POST হলে, স্টেটমেন্টটি মিথ্যা হিসেবে মূল্যায়ন করা হয়।

ডায়নামিক আচরণ চালু করতে, আপনি ফ্লো, ধাপ ও RouteRules-এ শর্তাবলী যোগ করতে পারেন।

আপনি কোনও Flow-তে শর্ত যোগ করলে, 'শর্তাধীন Flow' তৈরি করেন। শর্তাধীন ফ্লো শুধুমাত্র তখনই এক্সিকিউট হয় যখন শর্তটি সত্য হিসেবে মূল্যায়ন করা হয়। আপনি শর্তসাপেক্ষ ফ্লোতে যত খুশি নীতি অ্যাটাচ করতে পারবেন। কন্ডিশনাল ফ্লো আপনাকে নির্দিষ্ট মানদণ্ড পূরণ করে এমন অনুরোধ বা উত্তর মেসেজের জন্য অত্যন্ত বিশেষায়িত প্রসেসিং নিয়ম তৈরি করতে দেয়।

যেমন, এমন একটি ফ্লো তৈরি করতে যা শুধুমাত্র অনুরোধের ভার্ব 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>

আপনি এই ধরনের শর্তাধীন ফ্লো সংজ্ঞায়িত করার পরে, সেগুলির সাথে নীতি অ্যাটাচ করতে পারবেন, যা API প্রক্সিকে GET অনুরোধের জন্য এক সেট নীতি এবং POST অনুরোধের জন্য অন্য সেট নীতি প্রয়োগ করতে দেয়।

বিস্তারিত রেফারেন্স তথ্যের জন্য, নিম্নলিখিত রিসোর্স দেখুন:

নমুনা ১

নিম্নলিখিত উদাহরণে ProxyEndpoint রেসপন্স ফ্লোতে কনফিগার করা 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 সব HTTP হেডারের ভ্যালু ভেরিয়েবল হিসেবে স্টোর করে। অনুরোধে User-Agent নামের HTTP হেডার থাকলে, সেই হেডার এবং তার ভ্যালু request.header.User-Agent নামের ভেরিয়েবল হিসেবে সেভ করা হয়।

উপরে ProxyEndpoint কনফিগারেশন অনুযায়ী, Edge request.header.User-Agent ভেরিয়েবলের ভ্যালু চেক করে দেখে যে শর্তটি true হিসেবে মূল্যায়ন করা হয়েছে কিনা।

শর্তটি সত্য হলে, অর্থাৎ, ভেরিয়েবল request.header.User-Agent-এর মান Mozilla-এর সমান হলে, শর্তাধীন ফ্লো এক্সিকিউট হয় এবং ConvertToJSON নামের XMLtoJSON নীতি এনফোর্স করা হয়। না হলে, ফ্লো এক্সিকিউট করা হয় না এবং XML রেসপন্স কোনও পরিবর্তন না করেই (XML ফর্ম্যাটে) অনুরোধকারী অ্যাপে ফেরত পাঠানো হয়।

নমুনা ২

আসুন একটি নির্দিষ্ট উদাহরণ ব্যবহার করি যেখানে আপনাকে XML থেকে JSON-এ প্রতিক্রিয়া মেসেজ রূপান্তর করতে হবে—তবে শুধুমাত্র মোবাইল ডিভাইসের জন্য। প্রথমে, এমন নীতি তৈরি করুন যা Weather API থেকে পাওয়া XML-ফর্ম্যাটের রেসপন্সকে JSON-এ কনভার্ট করবে:

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

উপরের নীতি কনফিগারেশন API প্রক্সি-কে রেসপন্স মেসেজ নিতে, ডিফল্ট সেটিংস সহ XML থেকে JSON-এ কনভার্ট করতে এবং তারপর নতুন রেসপন্স মেসেজে ফলাফল লিখতে বলে। (আপনি যদি XML থেকে JSON-এ অনুরোধ মেসেজ কনভার্ট করেন, তাহলে আপনি এই দুটি ভ্যালুকেই request-এ সেট করতে পারেন।)

আপনি XML থেকে JSON-এ উত্তর কনভার্ট করতে চান বলে, কনভার্ট করার জন্য আপনাকে একটি শর্তাধীন উত্তর Flow কনফিগার করতে হবে। যেমন, ক্লায়েন্ট অ্যাপে ফেরত পাঠানোর আগে সব উত্তর XML থেকে JSON-এ কনভার্ট করতে, নিম্নলিখিত ProxyEndpoint উত্তর ফ্লো কনফিগার করুন।

<Flows>
  <Flow name="Convert-for-devices">
    <Response>
      <Step><Name>ConvertToJSON</Name></Step>
    </Response>
  </Flow>
</Flows>

স্ট্যান্ডার্ড অনুরোধ ব্যবহার করে API কল করলে, JSON ফর্ম্যাটে উত্তর পাওয়া যায়।

তবে, আপনার লক্ষ্য হল অনুরোধকারী ক্লায়েন্ট মোবাইল ডিভাইস হলে, শুধুমাত্র আবহাওয়ার রিপোর্ট JSON-এ কনভার্ট করা। এই ধরনের ডায়নামিক আচরণ চালু করতে, আপনাকে ফ্লোতে শর্তসাপেক্ষ স্টেটমেন্ট যোগ করতে হবে।

শর্তসাপেক্ষ ফ্লো পরীক্ষা করুন

এই স্যাম্পেল অনুরোধে, HTTP User-Agent হেডার Mozilla-এ সেট করা আছে, যার ফলে শর্তাধীন স্টেটমেন্ট true হিসেবে মূল্যায়ন করা হয় এবং শর্তাধীন ফ্লো 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-এর থেকে আলাদা ভ্যালু সহ কোনও অনুরোধ জমা দেওয়া হলে, XML-ফরম্যাট করা রেসপন্স পাওয়া যাবে।

$ curl http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

পরিবর্তন না করা XML উত্তর ফেরত পাঠানো হয়েছে।

নমুনা উত্তর:

<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" বা "~" কন্ডিশনাল অপারেটরটি দেখা যাক। এই দুটি অপারেটর একই -- ইংরেজি ভার্সন, "Matches", আরও সহজে পড়া যায় এমন বিকল্প হিসেবে বিবেচিত হয়।

সারসংক্ষেপ: "Matches" অপারেটর আপনাকে দুটি সম্ভাবনা দেখায়। স্ট্রিংটি আক্ষরিক অর্থে মেলান অথবা "*" দিয়ে ওয়াইল্ডকার্ড ম্যাচ করুন। আপনি যেমনটি আশা করতে পারেন, ওয়াইল্ডকার্ড শূন্য বা তার বেশি অক্ষরের সাথে মেলে। এটি কীভাবে কাজ করে তা দেখা যাক।

নিম্নলিখিত XML-এ একটি ধাপের শর্ত দেখানো হয়েছে। শর্তটি সত্য হলে এটি 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 এক্সিকিউট হবে? শুধু একটিই সম্ভাবনা আছে।

API কল:

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

নীতিটি কি কার্যকর হয়? হ্যাঁ, কারণ প্রক্সি পাথ সাফিক্স "/cat"-এর সাথে হুবহু মিলে যায়। সাফিক্স /bat বা /dog বা "/" বা অন্য কিছু হলে এটি কাজ করবে না।

এখন, এই শর্তসাপেক্ষ স্টেটমেন্টটি বিবেচনা করুন যেখানে আমরা ওয়াইল্ডকার্ড অক্ষর ব্যবহার করি "*":

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

API কল:

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

নীতিটি কি কার্যকর হয়? হ্যাঁ, কারণ ওয়াইল্ডকার্ড যেকোনও অক্ষরের সাথে ম্যাচ করে এবং "/cat" হল একটি ম্যাচ।

API কল:

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

নীতিটি কি কার্যকর হয়? হ্যাঁ, কারণ ওয়াইল্ডকার্ড যেকোনও অক্ষরের সাথে ম্যাচ করে, "/bat" একটি ম্যাচ।

API কল:

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

নীতিটি কি কার্যকর হয়? অবশ্যই নয় -- যদিও ওয়াইল্ডকার্ড "o"-এর সাথে মেলে, "wl" অক্ষরগুলি মেলে না।

এখন, ওয়াইল্ডকার্ডটি প্রত্যয়ের শেষে নিয়ে যাওয়া যাক:

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

API কল:

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

নীতিটি কি কার্যকর হয়? হ্যাঁ, কারণ ওয়াইল্ডকার্ড শূন্য বা তার বেশি যেকোনও অক্ষরের সাথে মেলে।

API কল:

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

নীতিটি কি কার্যকর হয়? "/bat" ম্যাচ করছে না।

API কল:

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

নীতিটি কি কার্যকর হয়? হ্যাঁ, ওয়াইল্ডকার্ড শূন্য বা তার বেশি যেকোনও অক্ষরের সাথে ম্যাচ করে, তাই "123" একটি ম্যাচ তৈরি করে।

API কল:

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

নীতিটি কি কার্যকর হয়? হ্যাঁ, কারণ ওয়াইল্ডকার্ড শূন্য বা তার বেশি যেকোনও অক্ষরের সাথে মেলে, তাই "/bird/mouse" একটি ম্যাচ তৈরি করে। মনে রাখবেন, এই ধরনের এক্সপ্রেশন আপনাকে সমস্যায় ফেলতে পারে, কারণ এটি আক্ষরিক অক্ষরের পরে থাকা সবকিছুর সাথে মিলে যায়!

প্রশ্ন: Matches অপারেটরের ক্ষেত্রে কি ছোট ও বড় হাতের অক্ষরের মধ্যে পার্থক্য করা হয়?

হ্যাঁ। ধরে নিন, আপনার কাছে এই ধরনের একটি শর্ত আছে:

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

API কল:

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

নীতিটি কি কার্যকর হয়? না, ওয়াইল্ডকার্ড যেকোনও অক্ষরের সাথে ম্যাচ করে (ছোট বা বড় হাতের অক্ষর যাই হোক না কেন), কিন্তু ছোট হাতের "a" বড় হাতের "A"-এর সাথে ম্যাচ করে না।

API কল:

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

নীতিটি কি কার্যকর হয়? হ্যাঁ, কেসটি মিলে গেছে।

প্রশ্ন: Matches অপারেটরের সাথে আমি কীভাবে এস্কেপ ক্যারেক্টার ব্যবহার করব?

রিজার্ভ করা অক্ষর এড়িয়ে যেতে শতাংশ "%" অক্ষর ব্যবহার করুন। যেমন:

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

API কল:

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

নীতিটি কি কার্যকর হয়? না, Matches অপারেটর আক্ষরিক স্ট্রিং "c*at" খুঁজছে।

API কল:

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

প্রশ্ন:নীতিটি কি কার্যকর হয়?

হ্যাঁ, এই পথটি একটু অন্যরকম হলেও, মিলে যায়।

JavaRegex

আপনি দেখতেই পাচ্ছেন, সহজ পরিস্থিতির জন্য "ম্যাচ" অপারেটর দারুণ কাজ করে। তবে আপনি অন্য অপারেটর, "JavaRegex" বা "~~" অপারেটর ব্যবহার করতে পারেন। এই দুটি একই অপারেটর, তবে JavaRegex আরও সহজে পড়া যায় বলে মনে করা হয়। এটি JavaRegex নামে পরিচিত কারণ এটি রেগুলার এক্সপ্রেশন প্যাটার্ন ম্যাচিংয়ের অনুমতি দেয় এবং Edge, Java ভাষার java.util.regex প্যাকেজ-এর ক্লাসগুলির মতো একই নিয়ম অনুসরণ করে। JavaRegex অপারেটর যেভাবে কাজ করে তা Matches অপারেটরের থেকে খুবই আলাদা, তাই এই দুটির মধ্যে গুলিয়ে ফেলবেন না!

সংক্ষিপ্তসার: "JavaRegex" অপারেটর আপনাকে শর্তসাপেক্ষ বিবৃতিতে রেগুলার এক্সপ্রেশন সিনট্যাক্স ব্যবহার করতে দেয়।

নিচের কোডটি একটি Step শর্ত দেখায়। শর্তটি সত্য হলে এটি 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 অপারেটরের মতোই, এই ক্ষেত্রেও শুধুমাত্র একটি সম্ভাবনা আছে।

API কল:

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

নীতিটি কি কার্যকর হয়? হ্যাঁ, কারণ প্রক্সি পাথ সাফিক্স "/cat"-এর সাথে হুবহু মিলে যায়। সাফিক্স /bat বা /dog বা অন্য কিছু হলে এটি এক্সিকিউট হবে না।

এখন, "*" কোয়ান্টিফায়ার ব্যবহার করে একটি রেগুলার এক্সপ্রেশন তৈরি করা যাক। এই কোয়ান্টিফায়ার পূর্ববর্তী অক্ষরের শূন্য বা তার বেশি সংখ্যার সাথে ম্যাচ করে।

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

API কল:

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

নীতিটি কি কার্যকর হয়? না! "*" কোয়ান্টিফায়ারটি পূর্ববর্তী অক্ষর, অর্থাৎ "c"-এর শূন্য বা তার বেশি সংখ্যার সাথে মেলে।

API কল:

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

নীতিটি কি কার্যকর হয়? হ্যাঁ, কারণ ওয়াইল্ডকার্ড পূর্ববর্তী অক্ষরের শূন্য বা তার বেশি অক্ষরের সাথে মিলে যায়।

এরপর, আমরা "?" কোয়ান্টিফায়ার ব্যবহার করি, যা আগের অক্ষর একবার বা একেবারেই ম্যাচ করে না।

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

API কল:

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

নীতিটি কি কার্যকর হয়? হ্যাঁ। "?" কোয়ান্টিফায়ার আগের অক্ষরটি শূন্য বা একবার ম্যাচ করে, যা হল "a"।

API কল:

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

নীতিটি কি কার্যকর হয়? হ্যাঁ। "?" কোয়ান্টিফায়ার পূর্ববর্তী অক্ষরের একটি বা কোনওটির সাথে মেলে না। এই ক্ষেত্রে, কোনও "a" অক্ষর নেই, তাই শর্তটি সত্য হিসেবে মূল্যায়ন করা হয়।

API কল:

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

নীতিটি কি কার্যকর হয়? না। "?" কোয়ান্টিফায়ার পূর্ববর্তী অক্ষরের একটির সাথে মেলে, যা হল "a"।

এরপর, আমরা "[abc]" বা "গ্রুপিং" স্টাইলের রেজেক্স এক্সপ্রেশন ব্যবহার করি। এটি "a" বা "b" বা "c" অক্ষরের সাথে মেলে।

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

API কল:

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>

API কল:

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

নীতিটি কি কার্যকর হয়? হ্যাঁ, রেজেক্স পূর্ববর্তী অক্ষরের শূন্য বা একটির সাথে মেলে, যা হল "a"।

API কল:

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 এক্সিকিউট হবে?

API কল:

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

প্রশ্ন: নীতিটি কি কার্যকর হয়?

না, কারণ "/*" দ্বারা নির্দিষ্ট করা শর্ত অনুযায়ী "/animals"-এর পরে আরেকটি পাথ এলিমেন্ট প্রয়োজন।

API কল:

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

নীতিটি কি কার্যকর হয়? হ্যাঁ, পাথে অন্য একটি পাথ এলিমেন্ট আছে ( "/animals/" চিহ্নের পরের অংশ), তবে সেটি খালি।

API কল:

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

নীতিটি কি কার্যকর হয়? হ্যাঁ, কারণ পাথে স্পষ্টতই একটি এলিমেন্ট ("/cats") আছে যা "/animals"-এর পরে আসে

API কল:

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

প্রশ্ন: নীতিটি কি কার্যকর হয়?

না, কারণ একটি অ্যাস্টেরিস্ক শুধুমাত্র একটি পাথ এলিমেন্টের সাথে মেলে এবং এই API-তে "/animals"-এর পরে একাধিক এলিমেন্ট আছে।

এখন ডবল অ্যাস্টেরিস্ক ব্যবহার করা যাক:

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

প্রশ্ন: কোন প্রক্সি পাথ সাফিক্সের কারণে SomePolicy এক্সিকিউট হবে?

API কল:

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

নীতিটি কি কার্যকর হয়? না, কারণ শর্তে "/**" দ্বারা নির্দিষ্ট করা অন্তত একটি নিম্নলিখিত পাথ এলিমেন্ট প্রয়োজন।

API কল:

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

নীতি কি কার্যকর হয়?

হ্যাঁ, পাথে অন্য একটি পাথ এলিমেন্ট আছে ("/animals/"-এর পরের অংশ), তবে এটি খালি।

API কল:

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

নীতি কি কার্যকর হয়?

হ্যাঁ, কারণ পাথে অন্তত একটি এলিমেন্ট আছে যা "/animals"-এর পরে আসে

API কল:

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>

API কল:

এইসব API কলের সবকটিই একটি ম্যাচ তৈরি করবে:

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

API রিসোর্স

RESTful পরিষেবা হল API রিসোর্স-এর সংগ্রহ। API রিসোর্স হল URI পাথ ফ্র্যাগমেন্ট যা এমন কিছু এন্টিটি শনাক্ত করে যা ডেভেলপাররা আপনার API কল করে অ্যাক্সেস করতে পারেন। যেমন, আপনার পরিষেবা যদি আবহাওয়ার রিপোর্ট ও আবহাওয়ার পূর্বাভাস প্রদান করে, তাহলে আপনার ব্যাকএন্ড পরিষেবা দুটি API রিসোর্স সংজ্ঞায়িত করতে পারে:

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

আপনি যখন API প্রক্সি তৈরি করেন (আপনার প্রথম API প্রক্সি তৈরি করুন-এ যেমন দেখানো হয়েছে), তখন আপনি অন্তত একটি উপনাম বেস URL তৈরি করছেন যা আপনার ব্যাকএন্ড পরিষেবার সাথে ম্যাপ করে। যেমন:

ব্যাকএন্ড বেস URL নতুন/সমতুল্য API প্রক্সি URL
http://mygreatweatherforecast.com http://{your_org}-{environment}.apigee.net/mygreatweatherforecast

এই পর্যায়ে আপনি যেকোনও বেস URL ব্যবহার করে আপনার ব্যাকএন্ডে API কল করতে পারবেন। কিন্তু আপনি যখন API প্রক্সি URL ব্যবহার করেন, তখন জিনিসগুলি আকর্ষণীয় হতে শুরু করে।

আপনি API প্রক্সি ব্যবহার করলে Edge যে API অ্যানালিটিক্স সংগ্রহ করা শুরু করে, তার পাশাপাশি প্রক্সি আপনাকে কন্ডিশনাল ফ্লোও নির্ধারণ করতে দেয় যা আপনার ব্যাকএন্ডের রিসোর্সের সাথে ম্যাপ করে। মূলত, "যদি /reports রিসোর্সে GET কল আসে, তাহলে Edge-এর কিছু করা উচিত।"

নিচের ছবিতে দুটি URL-এর মধ্যে আচরণের পার্থক্য দেখানো হয়েছে যা শেষ পর্যন্ত একই ব্যাকএন্ড অ্যাক্সেস করে। একটি হল আন-প্রক্সিড রিসোর্স URL, অন্যটি হল একই ব্যাকএন্ড রিসোর্সে শর্তসাপেক্ষ ফ্লো সহ Edge API প্রক্সি। আমরা নিচে শর্তসাপেক্ষ ফ্লো সম্পর্কে আরও বিস্তারিতভাবে আলোচনা করব।

API প্রক্সি কীভাবে নির্দিষ্ট ব্যাকএন্ড রিসোর্সে ম্যাপ করে

ব্যাকএন্ড পরিষেবার বেস URL-এ ম্যাপ করা API প্রক্সি URL-এর মাধ্যমে (আপনি যখন প্রক্সি তৈরি করেন), আপনি নির্দিষ্ট রিসোর্সে শর্তসাপেক্ষ ফ্লো যোগ করতে পারেন, যেমন আগে উল্লেখ করা /reports এবং /forecasts রিসোর্স।

ধরা যাক, আপনি চান যে /reports বা /forecasts রিসোর্সে কল এলে Edge "কিছু করুক"। এই মুহূর্তে আপনি Edge-কে বলছেন না যে কী করতে হবে, শুধু বলছেন যে সেইসব রিসোর্সের জন্য কল শুনতে হবে। আপনি শর্তাবলী সহ এটি করেন। আপনার Edge API প্রক্সিতে, আপনি /reports এবং /forecasts-এর জন্য শর্তসাপেক্ষ ফ্লো তৈরি করতে পারেন। ধারণাগত উদ্দেশ্যে, নিম্নলিখিত API প্রক্সি XML দেখায় যে সেই শর্তগুলি কেমন হতে পারে।

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

এই শর্তগুলি বলে, "যখন URL-এ /reports এবং /forecasts সহ একটি GET অনুরোধ আসে, তখন আপনি (API ডেভেলপার) যা করতে বলবেন, Edge তাই করবে, সেইসব ফ্লোতে আপনার অ্যাটাচ করা নীতির মাধ্যমে।

কোনও শর্ত পূরণ হলে Edge-কে কী করতে হবে তা বলার একটি উদাহরণ এখানে দেওয়া হল। নিম্নলিখিত API প্রক্সি XML-এ, যখন একটি GET অনুরোধ 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>

এইসব ঐচ্ছিক শর্তাধীন ফ্লো ছাড়াও, প্রতিটি API প্রক্সিতে দুটি ডিফল্ট ফ্লো থাকে: আপনার শর্তাধীন ফ্লোর আগে এক্সিকিউট করা <PreFlow> এবং আপনার শর্তাধীন ফ্লোর পরে এক্সিকিউট করা <PostFlow>। API প্রক্সিতে যেকোনও কল করা হলে নীতি প্রয়োগ করার জন্য সেগুলি উপযোগী। যেমন, আপনি যদি প্রতিটি কলের সাথে কোনও অ্যাপের API কী যাচাই করতে চান, ব্যাকএন্ড রিসোর্স অ্যাক্সেস করা হচ্ছে কিনা তা নির্বিশেষে, আপনি <PreFlow>-এ একটি API কী যাচাইকরণ নীতি রাখতে পারেন। ফ্লো সম্পর্কে আরও জানতে, ফ্লো কনফিগার করা দেখুন।

ব্যাকএন্ড রিসোর্সে শর্তাধীন ফ্লো তৈরি করুন

API প্রক্সিতে ব্যাকএন্ড রিসোর্সের জন্য শর্তাধীন ফ্লো নির্ধারণ করা সম্পূর্ণ ঐচ্ছিক। তবে, এই শর্তাধীন ফ্লো আপনাকে সূক্ষ্মভাবে ম্যানেজ ও মনিটর করার সুবিধা দেয়।

আপনি যা যা করতে পারবেন:

  • আপনার API মডেলের শব্দার্থবিদ্যাকে প্রতিফলিত করে এমনভাবে ম্যানেজমেন্ট প্রয়োগ করুন
  • আলাদা রিসোর্স পাথে (URI) নীতি ও স্ক্রিপ্ট করা আচরণ প্রয়োগ করুন
  • Analytics পরিষেবার জন্য সূক্ষ্ম-দানাদার মেট্রিক সংগ্রহ করুন

যেমন, ধরুন আপনার ব্যাকএন্ড /developers থেকে /apps রিসোর্সে বিভিন্ন ধরনের লজিক প্রয়োগ করতে হবে।

এটি করতে, আপনার API প্রক্সিতে দুটি শর্তাধীন ফ্লো যোগ করুন: /developers এবং /apps।

API প্রক্সি এডিটর নেভিগেটর প্যানেলের ডেভেলপ ভিউতে, প্রক্সি এন্ডপয়েন্টের ডিফল্ট বিকল্পের পাশে + আইকনে ক্লিক করুন।

"নতুন কন্ডিশনাল ফ্লো" উইন্ডোতে, আপনাকে নিম্নলিখিত কী কনফিগারেশন লিখতে হবে:

  • ফ্লো-এর নাম: ডেভেলপার
  • শর্তের ধরন: পাথ
  • পাথ: /developers

URI-এর শেষে /developers সহ প্রক্সিতে কল পাঠানো হলে শর্তটি ট্রিগার করা হবে (এবং নীতিগুলি কার্যকর করা হবে)।

এখন /apps-এর জন্য একটি কন্ডিশনাল ফ্লো যোগ করুন এবং ধরে নিন যে আপনি চান যে অনুরোধে URI এবং POST ভার্ব উভয়ের ক্ষেত্রেই কন্ডিশনটি ট্রিগার হোক। কনফিগারেশনের মধ্যে নিম্নলিখিত বিষয়গুলি সেট করা অন্তর্ভুক্ত:

  • ফ্লোর নাম: অ্যাপ
  • শর্তের ধরন: পাথ ও ভার্ব
  • পাথ: /apps
  • ক্রিয়া: POST

URI-এর শেষে /apps এবং POST ভার্ব সহ প্রক্সিতে কল পাঠানো হলে শর্তটি ট্রিগার করা হবে (এবং নীতিগুলি কার্যকর করা হবে)।

নেভিগেটর প্যানে, আপনি অ্যাপ এবং ডেভেলপারদের জন্য নতুন ফ্লো দেখতে পাবেন।

API প্রক্সি এডিটরের কোড ভিউতে শর্তাধীন ফ্লো কনফিগারেশন দেখতে ফ্লোর মধ্যে থেকে একটি বেছে নিন:

<Flow name="Apps">
    <Description>Developer apps registered in Developer Services</Description>
    <Request/>
    <Response/>
    <Condition>(proxy.pathsuffix MatchesPath "/apps") and (request.verb = "POST")</Condition>
</Flow>

আপনি দেখতে পাচ্ছেন, API রিসোর্স হল শর্তাধীন ফ্লো যা ইনবাউন্ড অনুরোধের URI পাথ মূল্যায়ন করে। (proxy.pathsuffix ভেরিয়েবলটি অনুরোধের URI শনাক্ত করে যা ProxyEndpoint কনফিগারেশনে কনফিগার করা BasePath অনুসরণ করে।)

আপনার সংজ্ঞায়িত প্রতিটি API রিসোর্স API প্রক্সিতে একটি শর্তসাপেক্ষ ফ্লো দ্বারা বাস্তবায়িত হয়। ( ফ্লো কনফিগার করা দেখুন।)

আপনি টেস্ট এনভায়রনমেন্টে API প্রক্সি ডিপ্লয় করার পরে, নিম্নলিখিত অনুরোধ:

http://{org_name}-test.apigee.net/{proxy_path}/apps

শর্তটি সত্য কিনা তা মূল্যায়ন করবে এবং এই ফ্লো, যেকোনও সংশ্লিষ্ট নীতির সাথে এক্সিকিউট করা হবে।

নিম্নলিখিত উদাহরণে দেখানো শর্তে, শেষে ফরওয়ার্ড স্ল্যাশ (/apps বা /apps/**) সহ বা ছাড়া /apps রিসোর্সে করা কল শনাক্ত করতে, জাভা রেগুলার এক্সপ্রেশন ব্যবহার করা হয়:

<Condition>(proxy.pathsuffix JavaRegex "/apps(/?)") and (request.verb = "POST")</Condition>

এই ধরনের শর্ত সম্পর্কে আরও জানতে, Apigee কমিউনিটি-তে ... নির্বিশেষে কীভাবে ম্যাচ করবেন দেখুন।

হায়ারার্কিক্যাল URI মডেলিং করা

কিছু ক্ষেত্রে, আপনার কাছে হায়ারার্কিক্যাল API রিসোর্স থাকবে। যেমন, Developer Services API এমন একটি পদ্ধতি প্রদান করে যার মাধ্যমে কোনও ডেভেলপারের সব অ্যাপের তালিকা দেখা যায়। URI পাথ হল:

/developers/{developer_email}/apps

আপনার কাছে এমন রিসোর্স থাকতে পারে যেখানে কোনও সংগ্রহের প্রতিটি এন্টিটির জন্য একটি অনন্য আইডি তৈরি করা হয়, যা কখনও কখনও নিম্নলিখিতভাবে অ্যানোটেট করা হয়:

/genus/:id/species

এই পাথ নিম্নলিখিত দুটি URI-এর ক্ষেত্রে সমানভাবে প্রযোজ্য:

/genus/18904/species
/genus/17908/species

API রিসোর্সে এই স্ট্রাকচার দেখাতে, আপনি ওয়াইল্ডকার্ড ব্যবহার করতে পারেন। যেমন:

/developers/*/apps
 
/developers/*example.com/apps
 
/genus/*/species

এইসব হায়ারার্কিক্যাল URI-কে API রিসোর্স হিসেবে যথাযথভাবে সমাধান করবে।

কিছু ক্ষেত্রে, বিশেষ করে গভীরভাবে হায়ারার্কিক্যাল API-এর জন্য, আপনি নির্দিষ্ট URI ফ্র্যাগমেন্টের নিচে সবকিছু সমাধান করতে চাইতে পারেন। এটি করতে, আপনার রিসোর্স সংজ্ঞায় ডবল অ্যাস্টেরিস্ক ওয়াইল্ডকার্ড ব্যবহার করুন। যেমন, আপনি যদি নিম্নলিখিত API রিসোর্স নির্ধারণ করেন: 
/developers/**

সেই API রিসোর্স নিম্নলিখিত URI পাথ সমাধান করবে:

/developers/{developer_email}/apps
/developers/{developer_email}/keys
/developers/{developer_email}/apps/{app_id}/keys

API প্রক্সি সংজ্ঞায় শর্তাধীন ফ্লো শর্ত কেমন দেখতে হবে তা এখানে দেওয়া হল:

<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/"। এর কারণ হল, কিছু ব্যবহারকারী বা ক্লায়েন্ট পাথের শেষে অতিরিক্ত স্ল্যাশ সহ আপনার API কল করতে পারেন এবং আপনার শর্তাধীন বিবৃতিতে আপনাকে সেটি ম্যানেজ করতে পারতে হবে। এই নির্দিষ্ট ব্যবহারের কেস Apigee কমিউনিটিতে আলোচনা করা হয়েছে।

আপনি চাইলে, Regex ব্যবহার না করেও এটি করতে পারেন:

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

এটি একটি ভালো বিকল্প। এটি স্পষ্ট ও পড়া যায়।

তবে, আপনি Regex-এর মাধ্যমে একই কাজ করতে পারেন, যেমন এটি। স্টেটমেন্টের regex অংশ গ্রুপ করতে বন্ধনী ব্যবহার করা হয়, তবে এটি আবশ্যক নয়।

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

API কল:

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

নীতিটি কি কার্যকর হয়? হ্যাঁ। মনে রাখবেন যে রেগুলার এক্সপ্রেশনে, "?" অক্ষরের অর্থ হল: আগের অক্ষরের শূন্য বা একটির সাথে মিল। তাই, "/cat" এবং "/cat/" উভয়ই ম্যাচ করে।

API কল:

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 এক্সপ্রেশনে ডবল কোটেশন চিহ্ন এড়িয়ে যাওয়া

শর্তের সিনট্যাক্সে JavaRegex এক্সপ্রেশন ডবল কোটের মধ্যে থাকতে হবে; তাই আপনার কাছে যদি এমন কোনও Regex এক্সপ্রেশন থাকে যাতে ডবল কোট আছে, তাহলে সেগুলি ম্যাচ করার জন্য আপনাকে অন্য কোনও উপায় অবলম্বন করতে হবে। উত্তর হল Unicode। যেমন, ধরা যাক আপনি ডবল কোট সহ একটি হেডার পাস করেছেন, যেমন: 
 -H 'content-type:multipart/related; type="application/xop+xml"'
 আপনি যদি Regex শর্তে সেই হেডার মেলানোর চেষ্টা করেন, তাহলে আপনি একটি ভুল শর্তের ত্রুটি পাবেন কারণ এক্সপ্রেশনে ডবল কোট অন্তর্ভুক্ত থাকে: 
request.header.Content-Type ~~ "(multipart\/related)(; *type="application\/xop\+xml\")"
 সমাধান হল ASCII-ভিত্তিক ডবল কোটকে তার ইউনিকোড সমতুল্য \u0022 দিয়ে প্রতিস্থাপন করা। যেমন, নিম্নলিখিত এক্সপ্রেশনটি সঠিক এবং প্রত্যাশিত ফলাফল প্রদান করে: 
request.header.Content-Type ~~ "(multipart\/related)(; *type=\u0022application\/xop\+xml\u0022)"