متغيّرات الطلب والاستجابة

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

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

  • عناوين الطلبات
  • مَعلمات طلب البحث
  • بيانات النموذج
  • حِمل XML أو JSON
  • معرّفات الموارد المنتظمة (URI)

يتم تلقائيًا تمرير جميع البيانات في الطلب بدون تغيير من ProxyEndpoint إلى TargetEndpoint. لذلك، عندما يرسل TargetEndpoint الطلب إلى خادم الخلفية، يتم تمرير جميع المعلومات الواردة في الطلب الأصلي إلى خدمة الخلفية.

وينطبق الشيء نفسه على الرد الذي تتلقّاه Edge من خدمة الخلفية. يتم تلقائيًا تمرير جميع البيانات الواردة في الرد بدون تغيير إلى التطبيق الذي أرسل الطلب.

كيف يتم تمرير بيانات الطلب إلى خادم الخلفية؟

تعرض الصورة التالية تعريفًا لخادم وكيل لواجهة برمجة التطبيقات:

طلب من عميل HTTP يمر عبر نقطة نهاية الخادم الوكيل إلى نقطة النهاية المستهدَفة على الخلفية للوصول إلى خدمة HTTP يتم تقديم أمثلة على نقطة نهاية الخادم الوكيل ونقطة نهاية الاستهداف.

بالنسبة إلى خادم وكيل واجهة برمجة التطبيقات هذا:

  • المضيف الافتراضي لخادم وكيل واجهة برمجة التطبيقات: "default"
  • النطاق الذي يحدّده المضيف الافتراضي: "http://myOrg-prod.apigee.net"
  • مسار الأساس للوكيل: "/v1/weather"
  • TargetEndpoint المحدّد بواسطة قاعدة التوجيه: "default"
  • عنوان URL الهدف: "http://weather.yahooapis.com"

يرسل تطبيق العميل طلب GET إلى خادم وكيل لواجهة برمجة التطبيقات باستخدام الأمر curl التالي:

curl -X GET http://myOrg-prod.apigee.net/v1/weather/forecastrss?w=12797282

لاحظ أنّ هذا الطلب يتضمّن المرجع "forecastrss" ومَعلمة طلب بحث واحدة، وهي w. تحلّل Edge الطلب كما هو موضّح أدناه وتعيّن أجزاء من الطلب لمتغيرات التدفق:

{request.verb} {proxy.basepath}/{proxy.pathsuffix}?{request.querystring}

يتم ضبط متغيّرات سير العمل بالقيم التالية:

  • request.verb: "GET"
  • proxy.basepath: "/v1/weather"
  • proxy.pathsuffix: "forecastrss"
  • request.querystring: "w=12797282"

بعد ذلك، يرسل TargetEndpoint طلبًا إلى خدمة الخلفية باستخدام معلومات من الطلب:

{request.verb} {target.basepath}/{proxy.pathsuffix}?{request.querystring}

لاحظ كيف يتم تضمين مَعلمات المورد وطلب البحث المحدّدة في الطلب تلقائيًا في الطلب المُرسَل إلى خادم الخلفية. من تعريف TargetEndpoint، يتخذ الطلب بعد ذلك الشكل التالي:

curl -X GET http://weather.yahooapis.com/forecastrss?w=12797282

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

curl -X GET -H 'Content-type:application/xml' http://myOrg-prod.apigee.net/v1/weather/forecastrss?w=12797282

أو طلبًا بالنموذج أدناه لتضمين عنوان وبيانات نموذج:

curl -X POST -H "Content-type:application/json" -d \
  '{"email" : "janetutorialxml@example.com",
    "firstName" : "Jane",
    "lastName" : "Tutorial",
    "userName" : "jtutorialxml"
  }' \
  http://myOrg-prod.apigee.net/v1/register/user

في كلا المثالين، يتم تمرير العناوين وبيانات النموذج بدون تغيير إلى خدمة الخلفية. يتم تمثيل العناوين باستخدام متغيّرات التدفق، مثل request.headers.count وrequest.headers.names. يتم تمثيل بيانات النموذج بواسطة متغيّرات التدفق، مثل request.formparam.count وrequest.formparam.names.

كيف يتم عرض بيانات الردود؟

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

الوصول إلى بيانات الطلبات والاستجابات في خادم وكيل لواجهة برمجة التطبيقات

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

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

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

رسائل طلب الوصول

يمكنك استخدام السياسات للوصول إلى أجزاء من رسالة الطلب وتغييرها. تشمل هذه الأجزاء ما يلي:

  • العناوين
  • مَعلمات طلب البحث
  • مَعلمات النموذج
  • عنوان IP المصدر
  • نص رسالة HTTP

في مسار عادي، بعد معالجة الطلب، يرسل الخادم الوكيل الطلب المحوَّل إلى الهدف.

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

الوصول إلى رسائل الرد

باستخدام المتغيرات التي تنطبق على رسالة الرد، يمكن أن تصل السياسات إلى مكوّنات الرسالة، بما في ذلك العنوان ومَعلمات طلب البحث ومَعلمات النموذج وعنوان IP المصدر ونص رسالة HTTP وما إلى ذلك.

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

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

السياسات الشائعة للوصول إلى متغيّرات التدفق

تحدّد Edge العديد من السياسات التي يمكنك استخدامها لمعالجة بيانات الطلبات والاستجابات. وتشمل هذه السياسات ما يلي:

  • سياسة AssignMessage: تنشئ هذه السياسة رسائل طلب أو استجابة HTTP أو تعدّلها أثناء عملية وكيل واجهة برمجة التطبيقات. يؤدي أيضًا إلى إنشاء متغيرات جديدة في مسار العمل وتعبئتها.
  • سياسة ExtractVariables: استخراج المحتوى من الرسائل، بما في ذلك العناوين ومسارات URI والحِملات ومَعلمات طلب البحث، لاستخدامها في عبارة شرطية تطبِّق السياسة بعد ذلك نمط نصي على محتوى الرسالة، وعند العثور على تطابق، يتم ضبط متغيّر محدّد.
  • سياسة JSONtoXML وسياسة XMLtoJSON: تحوّل الرسائل من تنسيق JavaScript Object Notation ‏ (JSON) إلى تنسيق لغة الترميز القابلة للتوسيع (XML) أو العكس.
  • سياسة JavaCallout وسياسة JavaScript وسياسة PythonScript وسياسة RegularExpressionProtection: تتيح لك هذه السياسات كتابة نص برمجي للوصول إلى متغيرات التدفق التي تحتوي على بيانات الطلبات والاستجابات.