প্রবাহ ভেরিয়েবল সহ শর্তাবলী

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

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

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

শর্তসাপেক্ষ বিবৃতি কনফিগার করুন

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

<Condition></Condition>

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

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

সমর্থিত শর্তসাপেক্ষ অপারেটরগুলির মধ্যে রয়েছে = (equals), != (সমান নয়), এবং > (এর চেয়ে বড়)। পঠনযোগ্যতার জন্য, আপনি শর্তসাপেক্ষগুলিকে টেক্সট হিসাবেও লিখতে পারেন: 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 হয়, তাহলে true হিসেবে মূল্যায়ন করা হয়। যদি অনুরোধের সাথে যুক্ত HTTP ক্রিয়াটি POST হয়, তাহলে বিবৃতিটি false হিসেবে মূল্যায়ন করা হয়।

গতিশীল আচরণ সক্ষম করতে, আপনি Flows, Steps এবং RouteRules-এর সাথে Conditions সংযুক্ত করতে পারেন।

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

উদাহরণস্বরূপ, এমন একটি 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>

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

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

উদাহরণ ১

নিচের উদাহরণে 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 ভেরিয়েবলের মান পরীক্ষা করে দেখে যে শর্তটি সত্য কিনা।

যদি শর্তটি সত্য হিসাবে মূল্যায়ন করে, অর্থাৎ, request.header.User-Agent ভেরিয়েবলের মান Mozilla সমান হয়, তাহলে শর্তসাপেক্ষ Flow কার্যকর হয় এবং ConvertToJSON নামক XMLtoJSON নীতি প্রয়োগ করা হয়। যদি তা না হয়, তাহলে Flow কার্যকর হয় না এবং 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-এ প্রতিক্রিয়া রূপান্তর করতে চান, তাই রূপান্তরটি সম্পাদন করার জন্য আপনাকে একটি শর্তসাপেক্ষ প্রতিক্রিয়া প্রবাহ কনফিগার করতে হবে। উদাহরণস্বরূপ, ক্লায়েন্ট অ্যাপে ফেরত পাঠানোর আগে XML থেকে JSON-এ সমস্ত প্রতিক্রিয়া রূপান্তর করতে, নিম্নলিখিত ProxyEndpoint প্রতিক্রিয়া প্রবাহটি কনফিগার করুন। 

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

যখন আপনি স্ট্যান্ডার্ড রিকোয়েস্ট ব্যবহার করে API চালু করেন, তখন প্রতিক্রিয়াটি JSON-এ ফর্ম্যাট করা হয়।

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

শর্তাধীন প্রবাহ পরীক্ষা করুন

এই নমুনা অনুরোধে, HTTP User-Agent হেডারটি Mozilla তে সেট করা হয়েছে, যার ফলে শর্তসাপেক্ষ বিবৃতিটি সত্য হিসাবে মূল্যায়ন করা হয় এবং শর্তসাপেক্ষ প্রবাহ Convert-for-devices কার্যকর করা হয়। 

$ curl -H "User-Agent:Mozilla" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

অথবা, যেখানে পাইথন পাওয়া যায় সেখানে সুন্দরভাবে প্রিন্ট করতে: 

$ 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", আরও পঠনযোগ্য বিকল্প হিসাবে বিবেচিত হয়।

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

নিম্নলিখিত XML একটি Step কন্ডিশন দেখায়। যখন কন্ডিশনটি true হিসাবে মূল্যায়ন করে তখন এটি 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 " একটি মিল তৈরি করে। লক্ষ্য করুন কিভাবে এই ধরনের একটি অভিব্যক্তি আপনাকে সমস্যায় ফেলতে পারে কারণ এটি আক্ষরিক অক্ষরের পরে সবকিছুর সাথে মেলে!

প্রশ্ন: ম্যাচ অপারেটর কি কেস সংবেদনশীল?

হ্যাঁ। ধরে নিন আপনার এইরকম একটা অবস্থা আছে: 

<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

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

API কল:

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

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

হ্যাঁ, এই পথটা, যদিও একটু অস্বাভাবিক, মিলে যায়।

জাভারেজেক্স

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

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

নিচের কোডটি একটি Step কন্ডিশন দেখায়। যদি কন্ডিশনটি true হিসেবে মূল্যায়ন করে তাহলে এটি 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] " অথবা "grouping" স্টাইলের regex এক্সপ্রেশন ব্যবহার করি। এটি " 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

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

না, কারণ condition-এর জন্য " /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 /পূর্বাভাস

যখন আপনি একটি API প্রক্সি তৈরি করেন (যেমনটি "আপনার প্রথম API প্রক্সি তৈরি করুন " এ দেখানো হয়েছে), তখন আপনি কমপক্ষে একটি উপনাম বেস 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>

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

এখন এখানে একটি উদাহরণ দেওয়া হল, যেখানে Edge-কে বলা হয়েছে যে কোন শর্ত পূরণ হলে কী করতে হবে। নিম্নলিখিত API প্রক্সি XML-এ, যখন https://yourorg-test.apigee.net/mygreatweatherforecast/reports এ একটি GET অনুরোধ পাঠানো হয়, তখন 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> এ একটি Verify API Key নীতি রাখতে পারেন। প্রবাহ সম্পর্কে আরও জানতে, প্রবাহ কনফিগার করা দেখুন।

ব্যাকএন্ড রিসোর্সে শর্তসাপেক্ষ প্রবাহ তৈরি করুন

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

তুমি সক্ষম হবে:

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

উদাহরণস্বরূপ, কল্পনা করুন যে আপনার ব্যাকএন্ড /ডেভেলপারদের /অ্যাপস রিসোর্সে বিভিন্ন ধরণের লজিক প্রয়োগ করতে হবে।

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

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

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

  • প্রবাহের নাম : ডেভেলপারগণ
  • শর্তের ধরণ : পথ
  • পথ : /ডেভেলপারগণ

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

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

  • প্রবাহের নাম : অ্যাপস
  • শর্তের ধরণ : পথ এবং ক্রিয়া
  • পথ : /অ্যাপস
  • ক্রিয়াপদ : POST

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

ন্যাভিগেটর ফলকে, আপনি Apps and Developers এর জন্য নতুন প্রবাহ দেখতে পাবেন।

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 ভেরিয়েবলটি ProxyEndpoint কনফিগারেশনে কনফিগার করা BasePath অনুসরণকারী অনুরোধের URI সনাক্ত করে।)

আপনার সংজ্ঞায়িত প্রতিটি 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 রিসোর্স থাকবে। উদাহরণস্বরূপ, ডেভেলপার সার্ভিসেস 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

একটি ব্যবহারিক উদাহরণ: পথের শেষে "/" উপেক্ষা করুন

এজ ডেভেলপাররা সাধারণত এই দুটি পাথ প্রত্যয়ই পরিচালনা করতে চান: " /cat " এবং " /cat/ "। এর কারণ হল কিছু ব্যবহারকারী বা ক্লায়েন্ট পাথের শেষে অতিরিক্ত স্ল্যাশ দিয়ে আপনার API কল করতে পারে এবং আপনার শর্তসাপেক্ষ বিবৃতিতে এটি পরিচালনা করতে সক্ষম হওয়া প্রয়োজন। এই সঠিক ব্যবহারের কেসটি Apigee Community-তে আলোচনা করা হয়েছে ।

আপনি যদি চান, তাহলে 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" হয় এবং নিয়মিত এক্সপ্রেশনটি "[az]" হয়, তাহলে কোনও মিল নেই, কারণ "[az]" ঠিক একটি আলফা অক্ষরের সাথে মেলে। "[az]+" এক্সপ্রেশনটি কাজ করে, যেমন "[az]*", এবং "[az]{3}"।

আসুন একটি সুনির্দিষ্ট উদাহরণ দেখি। ধরুন প্রমাণীকরণ সার্ভারটি কমা-বিচ্ছিন্ন স্ট্রিং হিসাবে ভূমিকাগুলির একটি তালিকা ফেরত দেয়: "সম্পাদক, লেখক, অতিথি"।

সম্পাদক ভূমিকার উপস্থিতি পরীক্ষা করার জন্য, এই নির্মাণটি কাজ করবে না, কারণ "সম্পাদক" সম্পূর্ণ স্ট্রিংয়ের একটি অংশ মাত্র।

<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 শর্তে সেই শিরোনামটি মেলানোর চেষ্টা করেন, তাহলে আপনি একটি Invalid Condition ত্রুটি পাবেন কারণ এক্সপ্রেশনটিতে ডাবল কোট রয়েছে:
request.header.Content-Type ~~ "(multipart\/related)(; *type="application\/xop\+xml\")"
 সমাধান হল ASCII-ভিত্তিক ডাবল কোটগুলিকে তাদের ইউনিকোড সমতুল্য দিয়ে প্রতিস্থাপন করা, \u0022 । উদাহরণস্বরূপ, নিম্নলিখিত এক্সপ্রেশনটি বৈধ এবং প্রত্যাশিত ফলাফল তৈরি করে:
request.header.Content-Type ~~ "(multipart\/related)(; *type=\u0022application\/xop\+xml\u0022)"