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

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

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

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

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

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

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

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

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

بالنسبة إلى خادم API الوكيل هذا:

  • المضيف الافتراضي لوكيل واجهة برمجة التطبيقات: "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: "التوقعات"
  • 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 للتحقّق من الطلبات. هذه المعلومات ليست مطلوبة من قِبل خدمة الخلفية.
  • لإضافة بيانات يتم إرسالها إلى خدمة الخلفية، على سبيل المثال لتتبُّع المستخدِمين أو جمع الإحصاءات
  • لمعالجة الطلب بشكل مشروط استنادًا إلى بيانات الطلب على سبيل المثال، يمكن أن يتضمّن الخادم الوكيل لواجهة برمجة التطبيقات عدة نقاط TargetEndpoints. يتم تحديد TargetEndpoint المستخدَم في الطلب من خلال بيانات الطلب. يمكنك بعد ذلك إزالة هذه البيانات من الطلب قبل إرساله إلى خدمة الخلفية.

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

الوصول إلى رسائل الطلبات

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

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

في المسار العادي، بعد معالجة الطلب، يُرسِل الخادم الوكيل الطلب الذي تم تحويله إلى الهدف.

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

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

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

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

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

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

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

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