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

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

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

এই বিষয়টি আপনাকে দেখায় যে কীভাবে কোনও কোড না লিখে, রানটাইমে 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} । তাই কন্টেন্ট-টাইপ হেডার মূল্যায়ন করতে, আপনি ভেরিয়েবল 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>

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

গতিশীল আচরণ সক্ষম করতে, আপনি প্রবাহ, পদক্ষেপ এবং রুট রুলস এর সাথে শর্ত সংযুক্ত করতে পারেন।

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

উদাহরণস্বরূপ, একটি ফ্লো তৈরি করতে যা শুধুমাত্র যখন অনুরোধ ক্রিয়াটি একটি GET হয় তখনই কার্যকর হয়:

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

GET-এর জন্য একটি ফ্লো এবং পোস্টগুলির জন্য আরেকটি ফ্লো তৈরি করতে:

<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 প্রক্সি সক্ষম করে তাদের সাথে নীতিগুলি সংযুক্ত করতে পারেন।

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

• ফ্লো ভেরিয়েবল রেফারেন্স
• শর্ত রেফারেন্স

উদাহরণ 1

নিম্নলিখিত উদাহরণটি Convert-for-devices নামে একটি একক শর্তসাপেক্ষ প্রবাহ দেখায়, যা ProxyEndpoint প্রতিক্রিয়া প্রবাহে কনফিগার করা হয়েছে। শর্তটি প্রযোজ্য সত্তার একটি উপাদান হিসাবে শর্ত যোগ করুন। এই উদাহরণে, শর্ত হল প্রবাহের একটি উপাদান। অতএব, যখনই বিবৃতিটি সত্যে মূল্যায়ন করবে তখনই প্রবাহ কার্যকর হবে৷

<Flows>
  <Flow name="Convert-for-devices">
  <Condition>(request.header.User-Agent = "Mozilla")</Condition>
    <Response>
      <Step><Name>ConvertToJSON</Name></Step>
    </Response>
  </Flow>
</Flows>

একটি অ্যাপ থেকে প্রাপ্ত প্রতিটি অনুরোধের জন্য, এজ ভেরিয়েবল হিসাবে উপস্থিত সমস্ত HTTP হেডারের মান সংরক্ষণ করে। যদি অনুরোধটিতে User-Agent নামক একটি HTTP শিরোনাম থাকে, তাহলে সেই শিরোনাম এবং এর মানটি request.header.User-Agent নামক একটি পরিবর্তনশীল হিসাবে সংরক্ষণ করা হয়।

উপরে প্রক্সিএন্ডপয়েন্ট কনফিগারেশন দেওয়া হয়েছে, এজ request.header.User-Agent ভেরিয়েবলের মান পরীক্ষা করে দেখে যে শর্তটি সত্যে মূল্যায়ন করে কিনা।

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

উদাহরণ 2

আসুন একটি নির্দিষ্ট উদাহরণ ব্যবহার করি যেখানে আপনাকে প্রতিক্রিয়া বার্তাকে XML থেকে JSON-এ রূপান্তর করতে হবে—কিন্তু শুধুমাত্র মোবাইল ডিভাইসের জন্য৷ প্রথমে, এমন নীতি তৈরি করুন যা আবহাওয়া 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-এ রূপান্তর করা যখন অনুরোধকারী ক্লায়েন্ট একটি মোবাইল ডিভাইস । এই ধরনের গতিশীল আচরণ সক্ষম করতে, আপনাকে অবশ্যই ফ্লোতে একটি শর্তসাপেক্ষ বিবৃতি যোগ করতে হবে।

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

এই নমুনা অনুরোধে, 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 ফ্লোতে অবস্থার সাথে প্যাটার্ন ম্যাচিং ব্যবহার করতে হয়।

আরও পড়া

অপারেটর

শর্তসাপেক্ষ বিবৃতিতে নিম্নলিখিত প্যাটার্ন ম্যাচিং অপারেটরগুলি কীভাবে ব্যবহার করবেন তা এই বিভাগটি বর্ণনা করে:

• ম্যাচ অপারেটর : সহজ প্যাটার্ন ম্যাচিং
• JavaRegex অপারেটর : মিলের উপর সূক্ষ্ম নিয়ন্ত্রণ
• ম্যাচসপাথ অপারেটর : পাথ ফ্র্যাগমেন্ট ম্যাচিং

মেলে

আসুন প্রথমে "ম্যাচ" বা "~" শর্তসাপেক্ষ অপারেটরটি দেখি। এই দুটি অপারেটর একই -- ইংরেজি সংস্করণ, "ম্যাচস", একটি আরও পাঠযোগ্য বিকল্প হিসাবে বিবেচিত হয়৷

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

নিম্নলিখিত XML একটি ধাপ শর্ত দেখায়. শর্তটি সত্যে মূল্যায়ন করলে এটি SomePolicy নীতি কার্যকর করে। এই উদাহরণে, আমরা ভেরিয়েবল proxy.pathsuffix পরীক্ষা করি, এজ-এ একটি বিল্ট-ইন ভেরিয়েবল যা অনুরোধের পাথ প্রত্যয় সংরক্ষণ করে। দ্রষ্টব্য, যাইহোক, আপনি একটি স্ট্রিং ধারণকারী যে কোনো ফ্লো ভেরিয়েবলের মান পরীক্ষা করতে পারেন। সুতরাং, এই ক্ষেত্রে, যদি ইনকামিং অনুরোধের বেস পাথ হয় /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

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

প্রশ্ন: ম্যাচ অপারেটরের সাথে আমি কীভাবে অক্ষরগুলি এড়িয়ে যেতে পারি?

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

<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

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

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

JavaRegex

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

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

নিম্নলিখিত কোড একটি ধাপ শর্ত দেখায়. শর্তটি সত্য হিসাবে মূল্যায়ন করলে এটি SomePolicy নীতি কার্যকর করে। এই উদাহরণে, আমরা ভেরিয়েবল proxy.pathsuffix পরীক্ষা করি, এজ-এ একটি বিল্ট-ইন ভেরিয়েবল যা অনুরোধের পাথ প্রত্যয় সংরক্ষণ করে। যদি ইনকামিং রিকোয়েস্টের বেস পাথ হয় /animals , এবং রিকোয়েস্টটি হয় /animals/cat , তাহলে পাথ প্রত্যয় হল আক্ষরিক স্ট্রিং " /cat "।

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix JavaRegex "/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 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 অপারেটরটিও এইভাবে নির্দিষ্ট করা যেতে পারে "~/"। এটি Matches (~) এবং JavaRegex (~~) অপারেটরগুলির মতো দেখতে কিছুটা। কিন্তু ম্যাচসপাথ সম্পূর্ণ আলাদা।

শুধু মনে রাখবেন যে এই অপারেটর অংশগুলির একটি সিরিজ হিসাবে একটি পথ দেখায়। অতএব, যদি পথটি হয়: /animals/cats/wild , আপনি পথটিকে " /animals ", " /cats " এবং " /wild " অংশ সমন্বিত হিসাবে ভাবতে পারেন।

MatchesPath অপারেটর আপনাকে দুটি ওয়াইল্ডকার্ড নোটেশন ব্যবহার করতে দেয়: একটি একক তারকাচিহ্ন (*) এবং একটি ডবল তারকাচিহ্ন (**)। একক তারকাচিহ্ন একটি পথ উপাদানের সাথে মেলে। ডাবল তারকাচিহ্ন এক বা একাধিক পথ উপাদানের সাথে মেলে।

এর একটি উদাহরণ তাকান. এই উদাহরণে, আমরা ভেরিয়েবল proxy.pathsuffix পরীক্ষা করি, এজ-এ একটি বিল্ট-ইন ভেরিয়েবল যা অনুরোধের পাথ প্রত্যয় সংরক্ষণ করে। দ্রষ্টব্য, যাইহোক, আপনি একটি স্ট্রিং ধারণকারী যে কোনো ফ্লো ভেরিয়েবলের মান পরীক্ষা করতে পারেন।

    <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 সম্পদ

আরামদায়ক পরিষেবাগুলি হল 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

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

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

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

এপিআই প্রক্সিগুলি কীভাবে নির্দিষ্ট ব্যাকএন্ড সংস্থানগুলিতে ম্যাপ করে

একটি API প্রক্সি ইউআরএল ব্যাকএন্ড পরিষেবার বেস ইউআরএলে ম্যাপ করে (যখন আপনি প্রক্সি তৈরি করেন), আপনি নির্দিষ্ট সংস্থানগুলিতে শর্তসাপেক্ষ প্রবাহ যোগ করতে পারেন, যেমন /reports এবং /forecasts সংস্থানগুলি আগে উল্লেখ করা হয়েছে।

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

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

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

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

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

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

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

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

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

• প্রবাহের নাম : বিকাশকারী
• অবস্থার ধরন : পথ
• পথ : /ডেভেলপারস

ইউআরআই-এর শেষে /ডেভেলপারদের সাথে প্রক্সিতে একটি কল পাঠানো হলে শর্তটি ট্রিগার করা হবে (এবং নীতিগুলি কার্যকর করা হবে)।

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

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

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

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

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

/developers/{developer_email}/apps

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

/genus/:id/species

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

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

এপিআই রিসোর্সে এই কাঠামোর প্রতিনিধিত্ব করতে, আপনি ওয়াইল্ডকার্ড ব্যবহার করতে পারেন। যেমন:

/developers/*/apps

/developers/*example.com/apps

/genus/*/species

উপযুক্তভাবে 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 কমিউনিটিতে আলোচনা করা হয়েছে ।

আপনি যদি চান, আপনি এই মত Regex ব্যবহার না করে এটি অর্জন করতে পারেন:

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

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>

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

এই উদাহরণে, আপনি ম্যাচ অপারেটরের সাথে "সম্পাদক" এর জন্যও পরীক্ষা করতে পারেন:

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

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

JavaRegex এক্সপ্রেশনে ডবল উদ্ধৃতি থেকে বেরিয়ে আসা

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

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