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

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

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

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

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

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

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

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

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

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

  • المضيف الافتراضي للخادم الوكيل لواجهة برمجة التطبيقات: "تلقائي"
  • النطاق مُحدد من قِبل المضيف الظاهري: "http://myOrg-prod.apigee.net"
  • مسار القاعدة الأساسية للخادم الوكيل: "/v1/weather"
  • نقطة نهاية الهدف التي تم تحديدها من خلال قاعدة المسار: "تلقائي"
  • عنوان URL المستهدف: "http://weather.yahoo.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 للتحقق من صحة الطلبات. ولا تطلب الخدمة الخلفية هذه المعلومات.
  • لإضافة بيانات يتم إرسالها إلى الخدمة الخلفية، من أجل تتبُّع المستخدمين أو جمع الإحصاءات مثلاً
  • معالجة الطلب بشكل مشروط استنادًا إلى بيانات الطلب على سبيل المثال، يمكن أن يشتمل الخادم الوكيل لواجهة برمجة التطبيقات على عدة نقاط نهاية لنقطة الهدف. يتم تحديد قيمة TargetEndpoint التي يستخدمها الطلب من خلال بيانات الطلب. وبعد ذلك، تزيل هذه البيانات من الطلب قبل إرسالها إلى خدمة الخلفية.

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

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

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

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

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

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

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

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

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

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

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

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

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