الشروط بمتغيّرات تدفق

أنت تعرض مستندات Apigee Edge.
انتقل إلى مستندات Apigee X. معلومات

العبارات الشرطية هي هيكل تحكم شائع في جميع لغات البرمجة. مثل فإن تهيئة خادم وكيل واجهة برمجة التطبيقات تدعم العبارات الشرطية للتدفقات، السياسات والخطوات وقواعد RouteRules. من خلال تعريف العبارات الشرطية، يمكنك تحديد السلوك الديناميكي لواجهة برمجة التطبيقات الخاصة بك. يتيح لك هذا السلوك الديناميكي تنفيذ إجراءات مثل تحويل XML إلى JSON فقط أجهزة الجوّال أو التوجيه إلى عنوان URL للواجهة الخلفية بناءً على نوع المحتوى أو فعل HTTP للطلب .

يوضِّح لك هذا الموضوع كيفية استخدام الشروط لتطبيق ميزات إدارة واجهة برمجة التطبيقات ديناميكيًا على بدون كتابة أي تعليمات برمجية.

إعداد العبارات الشرطية

يتم تنفيذ السلوك الشرطي في الخوادم الوكيلة لواجهة برمجة التطبيقات باستخدام مجموعة من الشروط والمتغيّرات. يتم إنشاء عبارة شرطية باستخدام عنصر شرط. ما يلي: عبارة عن شرط فارغ:

<Condition></Condition>

لإنشاء عبارة شرطية، يمكنك إضافة عامل شرطي ومتغير لإنشاء الهيكل التالي:

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

تتضمن العوامل الشرطية المعتمدة = (يساوي) و!= (غير يساوي) و> (أكبر من). من أجل سهولة القراءة، يمكنك أيضًا كتابة الشروط الشرطية على النحو التالي النص: equals، notequals، greaterthan.

عند العمل باستخدام مسارات معرّف الموارد المنتظم (URI)، يمكنك استخدام ~/ أو MatchesPath. يمكنك أيضًا مطابقة تعبيرات JavaRegex العادية مع عامل التشغيل ~~.

يتم استخدام الشروط لتحديد التدفقات الشرطية لخادم وكيل واجهة برمجة التطبيقات إلى موارد واجهة برمجة التطبيقات الخلفية، كما هو موضّح في إنشاء مسارات شرطية للموارد الخلفية لواجهة برمجة التطبيقات. بالنسبة قائمة كاملة من الشروط الشرطية، راجِع مرجع الشروط.

المتغيرات

تؤدي الشروط عملها من خلال تقييم قيم المتغيّرات. المتغير هو سمة لمعاملة HTTP تم تنفيذها بواسطة خادم وكيل لواجهة برمجة التطبيقات أو خاصية لخادم وكيل لواجهة برمجة التطبيقات التكوين نفسه. عندما يتلقى الخادم الوكيل لواجهة برمجة التطبيقات طلبًا من أحد التطبيقات، يملأ Apigee Edge قائمة طويلة من المتغيرات المرتبطة بأشياء مثل وقت النظام وشبكة التطبيق المعلومات وعناوين HTTP للرسائل وتهيئة الخادم الوكيل لواجهة برمجة التطبيقات وعمليات تنفيذ السياسات وما إلى ذلك. يؤدي هذا إلى إنشاء سياق غني يمكنك استخدامه لإعداد جمل شرطية.

تستخدِم المتغيرات دائمًا ترميزًا منقطًا. على سبيل المثال، عناوين 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>

تستخدم Edge هذه العبارة لتقييم الشروط. يقيّم المثال أعلاه القيمة true إذا كانت فعل HTTP المرتبط بالطلب هو GET. إذا كان فعل HTTP المرتبط بالطلب POST، ثم يتم تقييم العبارة إلى false.

لتفعيل السلوك الديناميكي، يمكنك إرفاق الشروط بالتدفقات والخطوات وقواعد المسار.

عند إرفاق شرط بتدفق، يمكنك إنشاء "تدفق مشروط". التدفقات الشرطية تنفيذه فقط عندما يتم تقييم الشرط إلى true. يمكنك إرفاق أي عدد تريده من السياسات. تدفقًا مشروطًا. يتيح لك التدفق المشروط صياغة قواعد معالجة عالية التخصص عن رسائل طلب أو رد تستوفي معايير معينة

على سبيل المثال، لإنشاء تدفق يتم تنفيذه فقط عندما يكون فعل الطلب هو 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 فقط إذا كانت رسالة الطلب مشاركة

<PreFlow name="PreFlow">
    <Request>
        <Step>
            <Condition>request.verb equals "POST"</Condition>
            <Name>VerifyApiKey</Name>
        </Step>
    </Request>
</PreFlow>

بعد تحديد هذه التدفقات المشروطة، يمكنك إرفاق "السياسات" بها، ما يفعّل واجهة برمجة تطبيقات خادم وكيل لفرض مجموعة واحدة من السياسات لطلبات GET، ومجموعة أخرى من السياسات لطريقة POST الطلبات.

للحصول على معلومات مرجعية شاملة، يمكنك الاطّلاع على المراجع التالية:

• مرجع متغيّرات التدفق
• مرجع الشروط

مثال 1

يوضح المثال التالي تدفقًا شرطيًا واحدًا باسم Convert-for-devices، في تدفق استجابة ProxyEndpoint. أضف الشرط كعنصر إلى الكيان إلى الذي ينطبق عليه الشرط. في هذا المثال، الشرط هو أحد مكونات التدفق. لذلك، سيتم تنفيذ التدفق عندما يتم تقييم العبارة على 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 الموجودة كـ المتغيرات. إذا كان الطلب يشتمل على عنوان HTTP يُسمى User-Agent، فإن هذا العنوان ويتم تخزين قيمته كمتغير يسمى request.header.User-Agent.

بناءً على تهيئة ProxyEndpoint أعلاه، تتحقق Edge من قيمة request.header.User-Agent لمعرفة ما إذا كانت الحالة يتم تقييمها إلى صواب.

إذا تم تقييم الشرط إلى true، أي أن قيمة المتغير request.header.User-Agent تساوي Mozilla، ثم التدفق المشروط وتنفيذ سياسة XMLtoJSON التي تُسمى ConvertToJSON. وإذا لم يكن الأمر كذلك، فإن التدفق ولا يتم تنفيذه، ويتم عرض استجابة XML بدون تعديل (بتنسيق XML) إلى الطلب التطبيق.

مثال 2

لنستخدم مثالاً محددًا تحتاج فيه إلى تحويل رسالة الرد من XML إلى JSON، ولكن للأجهزة الجوّالة فقط أولاً، أنشئ السياسة التي ستحوِّل استجابة بتنسيق XML من Weather API إلى 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، مما يتسبب في تقييم العبارة الشرطية إلى true ودالة الشرطية التدفق 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: أكثر دقة في المطابقة
• عامل تشغيل MatchPath: مطابقة أجزاء المسار

سلسلة مطابقة لـ

لنلقِ نظرة على "التطابقات" أو "~" عامل شرطي أولاً. هذان العاملان هما نفسه - تُعد النسخة الإنجليزية، "التطابقات"، خيارًا أكثر قابلية للقراءة.

ملخّص: نتيجة "التطابقات" الاحتمالية. تتطابق إمّا مع سلسلة حرفيًا، أو مطابقة حرف بدل مع "*". كما قد تتوقع، يتطابق حرف البدل مع صفر أو أكثر من الأحرف. لنرى كيف يعمل ذلك.

يعرض ملف XML التالي شرط الخطوة. وتنفِّذ سياسة somePolicy عندما يكون الشرط يتم تقييمه إلى true. في هذا المثال، نختبر المتغير 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" ينتج تطابقًا. لاحظ كيف يمكن لتعبير كهذا أن يجعلك في مشكلة لأنها تطابق كل شيء بعد الأحرف الحرفية!

سؤال: هل عامل تشغيل "التطابقات" حسّاس لحالة الأحرف؟

نعم. افترض أن لديك شرطًا مثل هذا:

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

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟ لا، يتطابق حرف البدل مع أي حرف (بغض النظر عن حالة الأحرف)، ولكن حرف "a" صغير لا تتطابق مع "A".

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟ نعم، هذا الطلب مطابق.

Question: كيف يمكنني إلغاء الأحرف باستخدام عامل تشغيل التطابقات؟

استخدام النسبة المئوية "%" لتخطي الأحرف المحجوزة. على سبيل المثال:

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

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟ لا، يبحث عامل التشغيل Match عن السلسلة الحرفية. "c*at".

طلب بيانات من واجهة برمجة التطبيقات:

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

السؤال:هل يتم تنفيذ السياسة؟

نعم، هذا المسار مطابق، على الرغم من أنّه غير معتاد إلى حد ما.

JavaRegex

كما ترى، "التطابقات" أمرًا رائعًا في المواقف البسيطة. لكن يمكنك استخدام "JavaRegex" أو "~~" . هذان هما نفس عامل التشغيل، باستثناء JavaRegex تعتبر أكثر قابلية للقراءة. ويُطلق عليها اسم JavaRegex لأنها تتيح التعبير العادي ، ويتبع Edge القواعد نفسها مثل الفئات في java.util.regex حزمة بلغة Java. الطريقة التي يعمل بها عامل تشغيل JavaRegex مختلفة تمامًا عن تتطابق مع عامل التشغيل، لذا من المهم عدم الخلط بين الاثنين.

الملخّص: "JavaRegex" يتيح لك استخدام بناء جملة التعبير العادي في العبارات الشرطية.

يعرض الرمز التالي أحد شروط الخطوة. وتنفِّذ هذه السياسة سياسة somePolicy إذا كان الشرط يتم تقييمه إلى true. في هذا المثال، نختبر المتغير proxy.pathsuffix، وهو متغير متغير في Edge يخزِّن لاحقة مسار الطلب. إذا كان المسار الأساسي يكون الطلب الوارد هو /animals، والطلب /animals/cat، ثم لاحقة المسار هي السلسلة الحرفية "/cat".

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

سؤال: ما هي لاحقة مسار الخادم الوكيل التي ستؤدي إلى تنفيذ somePolicy؟ تمامًا مثل باستخدام عامل تشغيل التطابقات، يكون هناك احتمال واحد فقط في هذه الحالة.

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟ نعم، لأن لاحقة مسار الخادم الوكيل تتطابق مع "/cat" بالضبط. لن يتم تنفيذها إذا كانت اللاحقة /bat أو /dog أو أي قيمة أخرى. آخر.

لننشئ الآن تعبيرًا عاديًا باستخدام "*". محدد الكمية. مُحدِّد الكمية هذا يطابق صفرًا أو أكثر من الحرف السابق.

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

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟ لا فإن "*" مُحدِّد الكمية يتطابق مع صفر أو أكثر من الحرف السابق، وهو "c".

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟ نعم، لأن حرف البدل لا يتطابق مع ما قبله أو أكثر الحرف.

بعد ذلك، نستخدم "?" محدد الكمية الذي يطابق الحرف السابق مرة واحدة، أو لا على الإطلاق.

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

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟ نعم. "?" مُحدِّد الكمية لا يتطابق مع صفر أو موضع ورود واحد الحرف السابق، وهو "a".

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟ نعم. "?" مُحدد الكمية يتطابق مع واحد أو لا شيء من الحرف السابق. في هذه الحالة، لا يوجد "a" الحرف، لذا فإن يتم تقييمه إلى قيمة true.

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟ لا، هل "؟" مُحدِّد الكمية يتطابق مع واحد من القيم السابقة وهو "a".

بعد ذلك، نستخدم "[abc]" أو "التجميع" نمط تعبير regex. تتطابق مع الأحرف "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 (~~) لكن MatchPath مختلف تمامًا.

تذكَّر فقط أنّ عامل التشغيل هذا ينظر إلى المسار كسلسلة من الأجزاء. لذلك، إذا لم يكن المسار هو: /animals/cats/wild، بإمكانك التفكير في المسار على أنه يتكون من أجزاء "/animals" و"/cats" و"/wild".

يتيح لك عامل التشغيل MatchesPath استخدام ترميزي حرف بدل: علامة نجمة واحدة (*) علامة نجمية مزدوجة (**). تتطابق علامة النجمة المفردة مع عنصر مسار واحد. تتطابق علامة النجمة المزدوجة عنصر مسار واحد أو أكثر.

لنلقِ نظرةً على المثال التالي. في هذا المثال، نختبر المتغير proxy.pathsuffix، متغير مضمّن في Edge يخزِّن لاحقة مسار الطلب. ومع ذلك، لاحظ أنه يمكنك لاختبار قيمة أي متغير تدفق يتضمن سلسلة.

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

سؤال: ما هي لاحقة مسار الخادم الوكيل التي ستؤدي إلى تنفيذ somePolicy؟

طلب بيانات من واجهة برمجة التطبيقات:

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

السؤال: هل يتم تنفيذ السياسة؟

لا، لأن الشرط يتطلب عنصر مسار آخر بعد "/animals"، كما هو محدَّد من "/*".

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟ نعم، يحتوي المسار على عنصر مسار آخر (الجزء الذي يلي "/animals/")، ولكنها فارغة فقط.

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟ نعم، لأنّ المسار يحتوي بوضوح على عنصر ("/cats"). الذي يأتي بعد "/animals"

طلب بيانات من واجهة برمجة التطبيقات:

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

السؤال: هل يتم تنفيذ السياسة؟

لا، نظرًا لأن علامة النجمة المفردة تتطابق فقط مع عنصر مسار واحد، تحتوي واجهة برمجة التطبيقات هذه على أكثر من عنصر بعد "/animals".

الآن، دعنا نستخدم علامة النجمة المزدوجة:

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

سؤال: ما هي لاحقة مسار الخادم الوكيل التي ستؤدي إلى تنفيذ somePolicy؟

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟ لا، لأن الشرط يتطلب عنصر مسار تتبع واحدًا على الأقل المحدد بواسطة "/**".

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟

نعم، يحتوي المسار على عنصر مسار آخر (الجزء الذي يلي "/animals/")، ولكنها فارغة فقط.

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟

نعم، لأنّ المسار يحتوي على عنصر واحد على الأقل يأتي بعد "/animals"

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟

نعم، لأنّ المسار يحتوي على أكثر من عنصر يأتي بعده "/animals"

مزج العلامات النجمية

يمكنك استخدام تركيبات من العلامة النجمية (*) والعلامة النجمية المزدوجة (**) لمزيد من التحسين مطابقة المسار.

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

طلب بيانات من واجهة برمجة التطبيقات:

وسينتج عن كل طلبات البيانات من واجهة برمجة التطبيقات مطابقة لما يلي:

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

GET http://artomatic-test.apigee.net/matchtest/animals/dogs/wild/austrailian
و

GET http://artomatic-test.apigee.net/matchtest/animals/birds/wild/american/finches

موارد واجهة برمجة التطبيقات

الخدمات REST هي مجموعات من موارد واجهة برمجة التطبيقات. مورد واجهة برمجة التطبيقات هو مسار URI يحدِّد كيانًا يمكن للمطوّرين الوصول إليه من خلال طلب واجهة برمجة التطبيقات. على سبيل المثال: إذا كانت خدمتك توفّر تقارير الطقس وتوقعات الطقس، يمكن أن تحدّد الخدمة الخلفية موردين لواجهة برمجة التطبيقات:

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

عندما تنشئ خادمًا وكيلاً لواجهة برمجة التطبيقات (كما هو موضح في قسم إنشاء أول خادم وكيل لواجهة برمجة التطبيقات)، يجب أن تنشئ عنوان URL أساسي للاسم المستعار المرتبط بخدمة الخلفية. على سبيل المثال:

في هذه المرحلة، يمكنك إجراء طلبات بيانات من واجهة برمجة التطبيقات إلى الواجهة الخلفية باستخدام أي من عناوين URL الأساسية. ولكن عند استخدام وعنوان URL للخادم الوكيل لواجهة برمجة التطبيقات، تبدأ الأمور في الجاذبية.

بالإضافة إلى تحليلات واجهة برمجة التطبيقات التي تبدأ Edge في جمعها عند استخدام الخادم الوكيل لواجهة برمجة التطبيقات والخوادم الوكيلة تتيح لك أيضًا تحديد التدفقات الشرطية التي ترتبط بالموارد الموجودة في الخلفية. في الواقع، "إذا يأتي استدعاء GET إلى مورد /reports، وينبغي أن يفعل Edge شيئًا ما".

توضح الصورة التالية الاختلاف في السلوك بين عنوانَي URL يصلان في النهاية إلى الواجهة الخلفية نفسها. أحدهما هو عنوان URL للمورد الذي لم يتم إنشاء خادم وكيل له، والآخر خادم وكيل Edge API تدفق شرطي إلى نفس مورد الخلفية. سنصف التدفقات الشرطية بمزيد من التفصيل أدناه.

كيفية ربط الخوادم الوكيلة لواجهة برمجة التطبيقات بموارد خلفية محددة

باستخدام عنوان URL للخادم الوكيل لواجهة برمجة التطبيقات تم ربطه بعنوان URL الأساسي لخدمة الخلفية (عند إنشاء الخادم الوكيل)، يمكنك إضافة تدفقات شرطية إلى موارد محددة، مثل /reports و/forecasts مصادر مذكورة سابقًا.

لنفترض أنك أردت جعل Edge "يفعل شيئًا" عندما تصل المكالمات إلى موارد /reports أو /forecasts أنت لا تخبر Edge في هذه المرحلة ما يجب فعله، على أنّه يجب أن يستمع إلى المكالمات الواردة إلى تلك الموارد. أنت تقوم بذلك بشروط. في خادم وكيل Edge API، يمكنك إنشاء تدفقات شرطية "/reports" و/forecasts" لأغراض مفاهيمية، تستخدم واجهة برمجة التطبيقات التالية الخادم الوكيل 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 أي طلب (مطوِّر واجهة برمجة التطبيقات) منه، من خلال السياسات التي تُرفِقها بتلك المسارات

الآن إليك مثال لإخبار Edge بما يجب فعله عند استيفاء شرط معين. في واجهة برمجة التطبيقات التالية الخادم الوكيل XML، عندما يتم إرسال طلب GET إلى https://yourorg-test.apigee.net/mygreatweatherforecast/reports، يتم تنفيذ Edge. ملف "XML-to-JSON-1" المستخدم في الرد.

<Flows>
    <Flow name="reports">
        <Description/>
        <Request/>
        <Response>
            <Step>
                <Name>XML-to-JSON-1</Name>
            </Step>
        </Response>
        <Condition>(proxy.pathsuffix MatchesPath "/reports") and (request.verb = "GET")</Condition>
</Flow>

بالإضافة إلى هذه التدفقات الشرطية الاختيارية، يأتي أيضًا كل خادم وكيل لواجهة برمجة التطبيقات مع اثنين التدفق: <PreFlow> يتم تنفيذه قبل التدفقات الشرطية، و يتم تنفيذ <PostFlow> بعد التدفقات الشرطية. هذه مفيدة وتنفيذ السياسات عند إجراء أي طلب إلى الخادم الوكيل لواجهة برمجة التطبيقات. على سبيل المثال، إذا كنت تريد التحقق من مفتاح واجهة برمجة التطبيقات للتطبيق في كل استدعاء، بغض النظر عن مورد الخلفية الذي يتم الوصول إليه، إضافة سياسة "مفتاح واجهة برمجة التطبيقات" إلى <PreFlow>. لمزيد من المعلومات حول التدفقات، اطّلع على إعداد التدفقات:

إنشاء تدفقات شرطية للموارد الخلفية

يعد تحديد التدفقات الشرطية للموارد الخلفية في الخادم الوكيل لواجهة برمجة التطبيقات اختياريًا تمامًا. ومع ذلك، تمنحك هذه التدفقات الشرطية القدرة على تطبيق إدارة المراقبة.

سيكون بإمكانك:

• تطبيق الإدارة بطريقة تعكس دلالات نموذج واجهة برمجة التطبيقات
• تطبيق السياسات والسلوك النصي على مسارات الموارد الفردية (URI)
• جمع مقاييس دقيقة لخدمات "إحصاءات Google"

على سبيل المثال، تخيل أنك بحاجة إلى تطبيق أنواع مختلفة من المنطق على الخلفية /developers إلى /apps.

لإجراء ذلك، عليك إضافة مسارَين شرطيَين في الخادم الوكيل لواجهة برمجة التطبيقات: /developers /apps

في قسم Develop view (تطوير طريقة عرض Navigator) لمحرّر واجهة برمجة التطبيقات الوكيل، انقر على رمز + بجوار الإعداد الافتراضي في نقاط نهاية الخادم الوكيل.

في "التدفق الشرطي الجديد" يمكنك إدخال التهيئات الرئيسية التالية:

• اسم التدفق: المطوِّرون
• نوع الشرط: المسار
• المسار: /developers

سيتم تشغيل الشرط (وسيتم تنفيذ السياسات) في حال إرسال طلب إلى الخادم الوكيل مع /developers في نهاية عنوان URI.

أضف الآن تدفقًا شرطيًا لـ /apps، وافترض أنك تريد تشغيل الشرط على كل من معرف الموارد المنتظم (URI) وفعل POST في الطلب. تتضمن التهيئة إعداد التالي:

• Flow Name: التطبيقات
• نوع الشرط: المسار والفعل
• المسار: /apps
• الفعل: POST

سيتم تشغيل الشرط (وسيتم تنفيذ السياسات) في حال إرسال طلب إلى الخادم الوكيل مع /apps في نهاية عنوان URI وفعل 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>

كما ترى، فإن موارد واجهة برمجة التطبيقات هي مجرد تدفقات مشروطة تقيّم مسار معرّف الموارد المنتظم (URI) طلب وارد. (يحدد متغيرproxy.pathsuffix عنوان URI للطلب الذي يلي BasePath الذي تم ضبطه في إعدادات ProxyEndpoint).

يتمّ تنفيذ كلّ مورد تحدّده لواجهة برمجة التطبيقات من خلال مسار مشروط في الخادم الوكيل لواجهة برمجة التطبيقات. (راجع إعداد التدفقات.)

بعد نشر الخادم الوكيل لواجهة برمجة التطبيقات في بيئة الاختبار، سيظهر الطلب التالي:

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

إلى تقييم الشرط على "صحيح"، وهذا التدفق، جنبًا إلى جنب مع أي السياسات.

يستخدم المثال التالي تعبير Java العادي للتعرف على الاتصالات التي يتم إجراؤها إلى مورد /apps مع شرطة مائلة للأمام أو بدونها (/apps أو /apps/**):

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

لمزيد من المعلومات عن هذا النوع من الشروط، اطّلِع على كيفية المطابقة بغض النظر ... في منتدى Apigee.

نمذجة معرّفات الموارد المنتظمة (URI) الهرمية

في بعض الحالات، ستكون لديك موارد واجهة برمجة تطبيقات هرمية. على سبيل المثال، تتضمن صفحة "خدمات المطورين" توفّر واجهة برمجة التطبيقات طريقة لإدراج جميع التطبيقات التي يملكها المطوِّر. مسار معرّف الموارد المنتظم (URI) هو:

/developers/{developer_email}/apps

قد يكون لديك موارد يتم فيها إنشاء رقم تعريف فريد لكل عنصر في إحدى المجموعات، أحيانًا تتم إضافة تعليقات توضيحية له على النحو التالي:

/genus/:id/species

ينطبق هذا المسار بالتساوي على عنوانَي URI التاليين:

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

لتمثيل هذه البنية في مورد واجهة برمجة التطبيقات، يمكنك استخدام أحرف البدل. على سبيل المثال:

/developers/*/apps

/developers/*example.com/apps

/genus/*/species

سيتم حل معرفات الموارد المنتظمة (URI) الهرمية هذه كموارد واجهة برمجة التطبيقات بشكل مناسب.

/developers/**

سيحل مورد واجهة برمجة التطبيقات هذا مسارات URI التالية:

/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/". ويرجع ذلك إلى أنّ بعض المستخدمين أو العملاء قد يتّصلون بواجهة برمجة التطبيقات مع والشرطة المائلة في نهاية المسار، وتحتاج إلى أن تكون قادرًا على التعامل مع ذلك في قسم البيانات. حالة الاستخدام هذه تمامًا تمت مناقشته على منتدى Apigee.

إذا كنت تفضل ذلك، يمكنك تحقيق ذلك دون استخدام التعبير العادي على النحو التالي:

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

يعد هذا خيارًا جيدًا. أنه واضح وسهل القراءة.

يمكنك أن تفعل الشيء نفسه مع التعبير العادي، مثل هذا. يتم استخدام الأقواس لتجميع جزء التعبير العادي من العبارة، لكنها ليست مطلوبة.

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

طلبات بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟ نعم. لاحظ أنه في التعبير العادي، لا يمكن اعتبار "?" يعني الحرف: عدم تطابقه مع أو واحد من الحرف السابق. لذلك، "/cat" و"/cat/" عبارة عن مطابقات.

طلب بيانات من واجهة برمجة التطبيقات:

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

هل يتم تنفيذ السياسة؟ لا، لأن التعبير العادي لا يطابق سوى موضع ورود واحد الحرف السابق، ولا يُسمح بأي شيء آخر.

مطابقة السلاسل العشوائية مع JavaRegex

في جميع الأمثلة في هذا الموضوع، نوضح كيفية مطابقة أحد متغيرات التدفق المضمنة: proxy.pathsuffix. من المفيد أن تعرف أنه يمكنك إجراء مطابقة أنماط على أي سلسلة عشوائية أو متغير التدفق، سواء كان متغير تدفق مدمج مثلproxy.pathsuffix.

على سبيل المثال، إذا كان لديك شرط يختبر سلسلة عشوائية، فربما يتم عرض سلسلة في حمولة الخلفية، أو سلسلة يتم إرجاعها من بحث خادم المصادقة، يمكنك استخدام ومطابقة المشغلات لاختباره. في حال استخدام JavaRegex، ستتم مقارنة التعبير العادي. مقابل سلسلة الموضوع بالكامل. إذا كان الموضوع هو "abc" والتعبير العادي هو "[a-z]", ما من مطابقة لأنّ "[a-z]" تتطابق تمامًا مع حرف ألفا واحد. تشير رسالة الأشكال البيانية التعبير "[a-z]+" مثل "[a-z]*" و"[a-z]{3}.

لنلقِ نظرة على مثال ملموس. لنفترض أن خادم المصادقة يعرض قائمة بالأدوار سلسلة تم حذفها بفواصل: "محرِّر، مؤلف، ضيف".

لاختبار توفُّر دور المحرِّر، لن تعمل هذه البنية، لأنّ "المحرر" CANNOT TRANSLATE جزءًا فقط من السلسلة بأكملها.

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

ومع ذلك، ستعمل هذه الطريقة:

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

وهي تعمل لأنها تراعي فواصل الكلمات وأي أجزاء أخرى من السلسلة تحتوي على .* البادئة واللاحقة.

في هذا المثال، يمكنك أيضًا اختبار كلمة "محرِّر" باستخدام عامل التشغيل التطابقات:

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

ومع ذلك، في الحالات التي تحتاج فيها إلى مزيد من الدقة، غالبًا ما يكون JavaRegex خيارًا أفضل.

الخروج من علامات الاقتباس المزدوجة في تعبيرات JavaRegex

 -H 'content-type:multipart/related; type="application/xop+xml"'

request.header.Content-Type ~~ "(multipart\/related)(; *type="application\/xop\+xml\")"

request.header.Content-Type ~~ "(multipart\/related)(; *type=\u0022application\/xop\+xml\u0022)"