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

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

শর্তসাপেক্ষ বিবৃতি (Conditional Statements) সকল প্রোগ্রামিং ভাষার একটি সাধারণ নিয়ন্ত্রণ কাঠামো। প্রোগ্রামিং ভাষার মতোই, এপিআই প্রক্সি কনফিগারেশন ফ্লো (Flows), পলিসি (Policies), স্টেপ (Steps), এবং রাউটরুল (RouteRules)-এর জন্য শর্তসাপেক্ষ বিবৃতি সমর্থন করে। শর্তসাপেক্ষ বিবৃতি সংজ্ঞায়িত করার মাধ্যমে, আপনি আপনার এপিআই-এর জন্য গতিশীল আচরণ (dynamic behaviour) নির্ধারণ করেন। এই গতিশীল আচরণ আপনাকে বিভিন্ন কাজ করতে দেয়, যেমন—শুধুমাত্র মোবাইল ডিভাইসের জন্য এক্সএমএল (XML)-কে জেএসওএন (JSON)-এ রূপান্তর করা, অথবা অনুরোধ বার্তার কন্টেন্ট টাইপ বা এইচটিটিপি ভার্ব (HTTP verb)-এর উপর ভিত্তি করে একটি ব্যাকএন্ড ইউআরএল (URL)-এ রাউটিং করা।

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

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

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

<Condition></Condition>

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

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

সমর্থিত শর্তাধীন অপারেটরগুলোর মধ্যে রয়েছে = (সমান), != (অসমান), এবং > (বৃহত্তর)। পাঠযোগ্যতার জন্য, আপনি শর্তাধীন অপারেটরগুলোকে টেক্সট হিসেবেও লিখতে পারেন: equals , notequals , greaterthan ।

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

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

ভেরিয়েবল

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

ভেরিয়েবল সবসময় ডটেড নোটেশন ব্যবহার করে। উদাহরণস্বরূপ, রিকোয়েস্ট মেসেজের 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 শর্তগুলো মূল্যায়ন করতে এই ধরনের স্টেটমেন্ট ব্যবহার করে। উপরের উদাহরণটি 'true' হিসেবে মূল্যায়ন করা হয় যদি অনুরোধের সাথে যুক্ত HTTP ভার্বটি GET হয়। আর যদি অনুরোধের সাথে যুক্ত HTTP ভার্বটি POST হয়, তাহলে স্টেটমেন্টটি 'false' হিসেবে মূল্যায়ন করা হয়।

ডাইনামিক আচরণ সক্রিয় করতে, আপনি ফ্লো, স্টেপ এবং রাউটরুল-এর সাথে কন্ডিশন সংযুক্ত করতে পারেন।

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

উদাহরণস্বরূপ, এমন একটি ফ্লো তৈরি করতে যা শুধুমাত্র তখনই কার্যকর হবে যখন অনুরোধের ভার্বটি 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>

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

বিস্তারিত তথ্যসূত্রের জন্য নিম্নলিখিত উৎসগুলো দেখুন:

উদাহরণ ১

নিম্নলিখিত উদাহরণটি ProxyEndpoint রেসপন্স ফ্লো-তে কনফিগার করা Convert-for-devices নামের একটি একক কন্ডিশনাল ফ্লো দেখায়। যে এনটিটির উপর শর্তটি প্রযোজ্য, তার একটি এলিমেন্ট হিসেবে Condition-টি যোগ করুন। এই উদাহরণে, শর্তটি ফ্লো-এর একটি কম্পোনেন্ট। সুতরাং, যখনই স্টেটমেন্টটি true হিসেবে ইভ্যালুয়েট হবে, ফ্লো-টি এক্সিকিউট হবে।

<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 সমান হয়, তাহলে শর্তাধীন ফ্লোটি কার্যকর হয় এবং ConvertToJSON নামক XMLtoJSON পলিসিটি প্রয়োগ করা হয়। অন্যথায়, ফ্লোটি কার্যকর হয় না এবং XML প্রতিক্রিয়াটি অপরিবর্তিত অবস্থায় (XML ফরম্যাটে) অনুরোধকারী অ্যাপে ফেরত পাঠানো হয়।

উদাহরণ ২

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

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

উপরের পলিসি কনফিগারেশনটি এপিআই প্রক্সিকে নির্দেশ দেয় যে, এটি যেন রেসপন্স মেসেজটি গ্রহণ করে, ডিফল্ট সেটিংস ব্যবহার করে সেটিকে 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>

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

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

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

এই নমুনা অনুরোধে, 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"-কে বেশি পাঠযোগ্য বিকল্প হিসেবে বিবেচনা করা হয়।

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

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

এপিআই কল:

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

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

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

জাভারেজেক্স

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

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

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

এপিআই কল:

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

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

এপিআই কল:

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 কার্যকর হবে?

এপিআই কল:

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 সার্ভিস হলো API রিসোর্সের একটি সংগ্রহ। একটি API রিসোর্স হলো একটি URI পাথের খণ্ডাংশ যা এমন কোনো সত্তাকে শনাক্ত করে, যা ডেভেলপাররা আপনার API কল করার মাধ্যমে অ্যাক্সেস করতে পারে। উদাহরণস্বরূপ, যদি আপনার সার্ভিস আবহাওয়ার প্রতিবেদন এবং পূর্বাভাস প্রদান করে, তাহলে আপনার ব্যাকএন্ড সার্ভিস দুটি API রিসোর্স সংজ্ঞায়িত করতে পারে:

  • http://mygreatweatherforecast.com /reports
  • http://mygreatweatherforecast.com /পূর্বাভাস

যখন আপনি একটি এপিআই প্রক্সি তৈরি করেন (যেমনটি ' আপনার প্রথম এপিআই প্রক্সি তৈরি করুন ' অংশে দেখানো হয়েছে), তখন আপনি ন্যূনতম একটি অ্যালিয়াস বেস ইউআরএল তৈরি করেন যা আপনার ব্যাকএন্ড সার্ভিসের সাথে ম্যাপ করা থাকে। উদাহরণস্বরূপ:

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

এই পর্যায়ে আপনি যেকোনো বেস ইউআরএল ব্যবহার করে আপনার ব্যাকএন্ডে এপিআই কল করতে পারেন। কিন্তু যখন আপনি এপিআই প্রক্সি ইউআরএল ব্যবহার করেন, তখন বিষয়টি আরও আকর্ষণীয় হয়ে ওঠে।

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

নিচের ছবিটি এমন দুটি URL-এর আচরণের পার্থক্য দেখাচ্ছে, যেগুলো শেষ পর্যন্ত একই ব্যাকএন্ড অ্যাক্সেস করে। একটি হলো প্রক্সিবিহীন রিসোর্স URL, এবং অন্যটি হলো একটি Edge 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 অনুরোধ আসে, তখন 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>

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

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

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

আপনি সক্ষম হবেন:

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

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

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

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

'New Conditional Flow' উইন্ডোতে, আপনাকে নিম্নলিখিত মূল কনফিগারেশনগুলি প্রবেশ করাতে হবে:

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

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

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

  • ফ্লো-এর নাম : অ্যাপস
  • শর্তের ধরণ : পথ এবং ক্রিয়া
  • পথ : /apps
  • ক্রিয়া : পোস্ট

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

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

এপিআই প্রক্সি এডিটর কোড ভিউতে শর্তসাপেক্ষ ফ্লো কনফিগারেশন দেখতে ফ্লোগুলোর মধ্যে একটি নির্বাচন করুন: 

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

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

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

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

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

এর ফলে শর্তটি সত্য বলে বিবেচিত হবে এবং এই ফ্লোটি, এর সাথে যুক্ত যেকোনো পলিসি সহ, কার্যকর হবে।

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

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

এই ধরনের অবস্থা সম্পর্কে আরও জানতে, Apigee কমিউনিটিতে ‘How to match regardless ...’ দেখুন।

শ্রেণিবদ্ধ ইউআরআই মডেলিং

কিছু ক্ষেত্রে, আপনার কাছে শ্রেণিবদ্ধ এপিআই রিসোর্স থাকবে। উদাহরণস্বরূপ, ডেভেলপার সার্ভিসেস এপিআই একজন ডেভেলপারের অন্তর্গত সমস্ত অ্যাপ তালিকাভুক্ত করার জন্য একটি পদ্ধতি প্রদান করে। ইউআরআই পাথটি হলো: 

/developers/{developer_email}/apps

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

/genus/:id/species

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

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

একটি এপিআই রিসোর্সে এই কাঠামোটি উপস্থাপন করতে, আপনি ওয়াইল্ডকার্ড ব্যবহার করতে পারেন। উদাহরণস্বরূপ: 

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

এই শ্রেণিবদ্ধ URI-গুলিকে যথাযথভাবে API রিসোর্স হিসাবে সমাধান করা হবে।

কিছু ক্ষেত্রে, বিশেষ করে গভীরভাবে স্তরবিন্যস্ত API-গুলোর জন্য, আপনি হয়তো একটি নির্দিষ্ট URI খণ্ডের নীচের সবকিছু রিজলভ করতে চাইতে পারেন। এটি করার জন্য, আপনার রিসোর্স সংজ্ঞায়নে একটি ডাবল অ্যাস্টারিস্ক ওয়াইল্ডকার্ড ব্যবহার করুন। উদাহরণস্বরূপ, যদি আপনি নিম্নলিখিত 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-এর সাথে সংযুক্ত শর্ত 

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

এটি একটি ভালো বিকল্প। এটি স্পষ্ট এবং পাঠযোগ্য।

তবে, আপনি রেজেক্স (Regex) ব্যবহার করেও একই কাজ করতে পারেন, ঠিক এইভাবে। স্টেটমেন্টের রেজেক্স অংশটিকে একত্রিত করার জন্য বন্ধনী ব্যবহার করা হয়, কিন্তু এটি আবশ্যক নয়। 

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

এপিআই কল:

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

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

এপিআই কল:

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

পলিসিটি কি কার্যকর হয়? না। রেগুলার এক্সপ্রেশনটি পূর্ববর্তী ক্যারেক্টারের শূন্য বা শুধুমাত্র একটি উপস্থিতিকেই ম্যাচ করে এবং অন্য কিছুই অনুমোদিত নয়।

JavaRegex ব্যবহার করে যথেচ্ছ স্ট্রিং মেলানো

এই টপিকের সমস্ত উদাহরণে, আমরা দেখিয়েছি কিভাবে একটি বিল্ট-ইন ফ্লো ভ্যারিয়েবল—proxy.pathsuffix—ম্যাচ করতে হয়। এটা জেনে রাখা ভালো যে, আপনি যেকোনো স্ট্রিং বা ফ্লো ভ্যারিয়েবলের উপর প্যাটার্ন ম্যাচিং করতে পারেন, সেটি proxy.pathsuffix-এর মতো বিল্ট-ইন ফ্লো ভ্যারিয়েবল হোক বা না হোক।

উদাহরণস্বরূপ, যদি আপনার এমন কোনো শর্ত থাকে যা একটি যথেচ্ছ স্ট্রিং পরীক্ষা করে, যেমন—ব্যাকএন্ড পেলোডে প্রাপ্ত কোনো স্ট্রিং, বা কোনো অথেনটিকেশন সার্ভার লুকআপ থেকে প্রাপ্ত স্ট্রিং—তবে আপনি এটি পরীক্ষা করার জন্য ম্যাচিং অপারেটর ব্যবহার করতে পারেন। আপনি যদি JavaRegex ব্যবহার করেন, তাহলে রেগুলার এক্সপ্রেশনটি সম্পূর্ণ সাবজেক্ট স্ট্রিংটির সাথে তুলনা করা হবে। যদি সাবজেক্টটি "abc" হয় এবং রেগুলার এক্সপ্রেশনটি "[az]" হয়, তাহলে কোনো মিল পাওয়া যাবে না, কারণ "[az]" ঠিক একটি আলফা ক্যারেক্টারের সাথে মেলে। "[az]+" এক্সপ্রেশনটি কাজ করে, যেমনটি "[az]*" এবং "[az]{3}" করে।

চলুন একটি বাস্তব উদাহরণ দেখা যাক। ধরুন, অথেনটিকেশন সার্ভারটি কমা দিয়ে আলাদা করা একটি স্ট্রিং হিসেবে রোলের একটি তালিকা ফেরত দেয়: "editor, author, guest"।

এডিটর রোলের উপস্থিতি যাচাই করার জন্য এই গঠনটি কাজ করবে না, কারণ 'editor' সম্পূর্ণ স্ট্রিংটির কেবল একটি অংশ।

<Condition>returned_roles ~~ "editor"</Condition>

তবে এই নির্মাণটি কাজ করবে:

<Condition>returned_roles ~~ ".*\beditor\b.*")</Condition>

এটি কাজ করে কারণ এটি শব্দের বিভাজন এবং স্ট্রিংয়ের .* উপসর্গ ও প্রত্যয়যুক্ত অন্য যেকোনো অংশকে বিবেচনায় নেয়।

এই উদাহরণে, আপনি Matches অপারেটর ব্যবহার করে 'editor' এর জন্য পরীক্ষা করতে পারেন:

<Condition>returned_roles ~~ "*editor*")</Condition>

তবে, যেসব ক্ষেত্রে আরও বেশি নির্ভুলতার প্রয়োজন হয়, সেখানে JavaRegex প্রায়শই একটি ভালো বিকল্প।

JavaRegex এক্সপ্রেশনে ডাবল কোট এস্কেপ করা

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