ما هي السياسة؟

أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

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

لا يقتصر الأمر على مجموعة أنواع السياسات التي توفّرها Apigee Edge. يمكنك أيضًا كتابة نصوص برمجية ورموز مخصّصة (مثل تطبيقات JavaScript وNode.js) تعمل على توسيع وظائف خادم وكيل لواجهة برمجة التطبيقات وتتيح لك الابتكار استنادًا إلى إمكانات الإدارة الأساسية التي تتيحها سياسات Apigee.

شاهِد هذا الفيديو للحصول على مقدمة عن ربط السياسات وتنفيذها.

أنواع السياسات

من الناحية الفنية، السياسة هي ملف إعداد بتنسيق XML. يتم تحديد بنية كل نوع من أنواع السياسات (على سبيل المثال، عناصر الإعداد المطلوبة والاختيارية) من خلال مخطط XML. إذا كنت على دراية جيدة بأدوات XML، ننصحك بالتعرّف على مخططات السياسات في عينات "منصة واجهة برمجة التطبيقات" على Github.

يتم تجميع أنواع "سياسات Edge" في الفئات الوظيفية التالية:

إدارة عدد الزيارات

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

الأمان

تتيح السياسات في فئة الأمان المصادقة والتفويض، بالإضافة إلى الأمان المستند إلى المحتوى.

الوساطة

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

الإضافة

تتيح لك السياسات في فئة الإضافات الاستفادة من إمكانية توسيع نطاق "خدمات واجهة برمجة التطبيقات" لتنفيذ سلوك مخصّص بلغة البرمجة التي تختارها.

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

تنفيذ تغييرات السياسة

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

التحقّق من تنفيذ السياسة

للتحقّق من تطبيق السياسة بشكلٍ صحيح، يجب أن يستدعي عميل HTTP واجهة برمجة التطبيقات. للتحقّق من صحة إعدادات الحصة هذه، أرسِل طلبات متعددة إلى واجهة برمجة التطبيقات تتجاوز حد الحصة الذي ضبطته في سياسة الحصة. (مسار URI، الذي تم ضبطه كإعداد المسار الأساسي في ProxyEndpoint، في الطلب أدناه هو /weather).

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

بعد إرسال أكثر من طلب واحد في الدقيقة، من المفترض أن تظهر لك رسالة الخطأ التالية:

{  
   "fault":{  
      "faultstring":"policies.ratelimit.QuotaViolation",
      "detail":{  
         "errorcode":"policies.ratelimit.QuotaViolation"
      }
   }
}

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

معالجة الأخطاء المستندة إلى السياسات

لاحظ تنسيق رسالة الخطأ أعلاه. ويحتوي على موقع faultstring وموقع errorcode. في كثير من الحالات، عليك تنفيذ بعض السلوكيات للتعامل مع هذه الأخطاء. على سبيل المثال، قد تحتاج إلى إصدار رسالة مخصّصة لمطوّر تجاوز تطبيقه الحصة المحدّدة.

لمزيد من المعلومات حول معالجة الأخطاء، يُرجى الاطّلاع على معالجة الأخطاء.

أفضل الممارسات: مجموعات السياسات الشائعة

لاستيفاء متطلبات الإدارة الأساسية، تفرض خوادم وكيل واجهة برمجة التطبيقات عادةً السياسات التالية:

التحقّق الأساسي من صحة مفتاح واجهة برمجة التطبيقات

مسار طلب ProxyEndpoint:
  1. SpikeArrest
  2. XMLThreatProtection أو JSONThreatProtection
  3. التحقّق من صحة مفتاح واجهة برمجة التطبيقات
  4. الحصة
  5. ResponseCache
تسلسل الردّ في ProxyEndpoint:
  1. ResponseCache

التحويل الأساسي: من JSON إلى XML

مسار الطلب:
  1. SpikeArrest
  2. JSONThreatProtection
  3. التحقّق من صحة مفتاح واجهة برمجة التطبيقات
  4. الحصة
  5. JSONToXML
مسار الردّ:
  1. XMLToJSON
  2. ResponseCache