أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلى
مستندات Apigee X. info
في Apigee Edge، يتعامل الموجّه مع جميع زيارات واجهة برمجة التطبيقات الواردة. وهذا يعني أنّ جميع طلبات HTTP وHTTPS الموجّهة إلى خادم وكيل لواجهة برمجة التطبيقات في Edge تتم معالجتها أولاً من خلال Edge Router. لذلك، يجب توجيه طلبات خادم وكيل لواجهة برمجة التطبيقات إلى عنوان IP ومنفذ مفتوح على جهاز توجيه.
يتيح لك المضيف الظاهري استضافة أسماء نطاقات متعددة على خادم واحد أو مجموعة من الخوادم. بالنسبة إلى Edge، تتوافق الخوادم مع أجهزة توجيه Edge. من خلال تحديد المضيفات الافتراضية على جهاز توجيه، يمكنك التعامل مع الطلبات الواردة إلى نطاقات متعددة.
يحدّد المضيف الافتراضي على Edge بروتوكولاً (HTTP أو HTTPS)، بالإضافة إلى منفذ جهاز التوجيه واسم مستعار للمضيف. اسم المضيف البديل هو عادةً اسم نطاق نظام أسماء النطاقات الذي يرتبط بعنوان IP الخاص بجهاز التوجيه.
على سبيل المثال، تعرض الصورة التالية جهاز توجيه يتضمّن تعريفَين للمضيف الافتراضي:
في هذا المثال، هناك تعريفان للمضيف الافتراضي. يتعامل أحدهما مع طلبات HTTPS على النطاق domainName1، ويتعامل الآخر مع طلبات HTTP على domainName2.
عند إرسال طلب إلى خادم وكيل لواجهة برمجة التطبيقات، يقارن جهاز التوجيه عنوان Host ورقم المنفذ للطلب الوارد بقائمة أسماء المضيفين البديلة المحدّدة من خلال جميع المضيفين الظاهريين لتحديد المضيف الظاهري الذي سيتعامل مع الطلب.
في ما يلي نموذج إعداد للمضيفات الافتراضية:
نمط مضاد
سيؤدي تحديد مضيفات افتراضية متعددة باستخدام اسم مستعار للمضيف ورقم المنفذ نفسهما في البيئات نفسها أو المختلفة لمؤسسة أو في مؤسسات مختلفة إلى حدوث التباس عند توجيه طلبات واجهة برمجة التطبيقات، وقد يتسبب ذلك في حدوث أخطاء أو سلوك غير متوقع.
لنستخدِم مثالاً لتوضيح الآثار المترتبة على توفّر مضيفات افتراضية متعددة تحمل الاسم المستعار نفسه للمضيف.
لنفترض أنّ هناك مضيفَين افتراضيَّين sandbox and secure محدَّدَين
بالاسم المستعار نفسه للمضيف، أي api.company.abc.com في بيئة:
مع عملية الإعداد الموضّحة أعلاه، يمكن أن يحدث أحد السيناريوهَين الموضّحَين في الأقسام التالية.
السيناريو 1 : تم ضبط خادم وكيل لواجهة برمجة التطبيقات لقبول الطلبات إلى أحد مضيفي sandbox الظاهريين فقط
<ProxyEndpoint name="default">
...
<HTTPProxyConnection>
<BasePath>/demo</BasePath>
<VirtualHost>sandbox</VirtualHost>
</HTTPProxyConnection>
...
</ProxyEndpoint>في هذا السيناريو، عندما ترسل تطبيقات العميل طلبات إلى خادم وكيل API محدّد باستخدام اسم المضيف البديل api.company.abc.com، ستتلقّى بشكل متقطع أخطاء 404 مع الرسالة التالية:
Unable to identify proxy for host: secure
ويرجع ذلك إلى أنّ جهاز التوجيه يرسل الطلبات إلى كل من الأجهزة المضيفة الافتراضية sandbox وsecure. عندما يتم توجيه الطلبات إلى المضيف الافتراضي sandbox، ستتلقّى تطبيقات العميل ردًا ناجحًا. ومع ذلك، عند توجيه الطلبات إلى المضيف الظاهري secure، ستتلقّى تطبيقات العميل الخطأ 404 لأنّ خادم وكيل واجهة برمجة التطبيقات لم يتم إعداده لقبول الطلبات على المضيف الظاهري secure.
السيناريو 2 : تم ضبط خادم وكيل لواجهة برمجة التطبيقات لقبول الطلبات إلى كلّ من وضع الحماية الآمن والمضيفين الظاهريين
<ProxyEndpoint name="default">
...
<HTTPProxyConnection>
<BasePath>/demo</BasePath>
<VirtualHost>sandbox</VirtualHost>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
...
</ProxyEndpoint>في هذا السيناريو، عندما تقدّم تطبيقات العميل طلبات إلى خادم وكيل API معيّن باستخدام اسم المضيف البديل api.company.abc.com، ستتلقّى استجابة صالحة استنادًا إلى منطق الخادم الوكيل.
ومع ذلك، يؤدي ذلك إلى تخزين بيانات غير صحيحة في "إحصاءات Google" لأنّه يتم توجيه طلبات البيانات من واجهة برمجة التطبيقات إلى كلّ من المضيفَين الافتراضيَين، بينما كان من المفترض أن يتم إرسال الطلبات الفعلية إلى مضيف افتراضي واحد فقط.
يمكن أن يؤثّر ذلك أيضًا في معلومات التسجيل وأي بيانات أخرى تستند إلى المضيفات الافتراضية.
التأثير
- أخطاء 404 لأنّه قد يتم توجيه طلبات البيانات من واجهة برمجة التطبيقات إلى مضيف افتراضي قد لا يكون وكيل واجهة برمجة التطبيقات معدًا لقبول الطلبات.
- بيانات "إحصاءات Google" غير صحيحة لأنّه يتم توجيه طلبات البيانات من واجهة برمجة التطبيقات إلى جميع المضيفات الافتراضية التي تحمل الاسم المستعار نفسه للمضيف، بينما تم تقديم الطلبات لمضيف افتراضي محدّد فقط.
أفضل الممارسات
- لا تحدّد مضيفات افتراضية متعددة باستخدام اسم مستعار للمضيف ورقم المنفذ نفسهما في البيئة نفسها أو في بيئات مختلفة ضمن المؤسسة نفسها.
إذا كان من الضروري تحديد مضيفات افتراضية متعددة، استخدِم أسماء مستعارة مختلفة للمضيف في كل مضيف افتراضي كما هو موضّح أدناه:
