أقوم بإرفاق تطبيق بمنتج لا يحتوي على وكلاء.أي محاذير؟

Question

هناك 3 سيناريوهات للتطبيق والأسئلة التالية.

---

خلفية

افترض أن جميع واجهات برمجة التطبيقات باستثناء وكيل OAuth-ClientCredentials محمية بواسطة سياسة OAuth/VerifyAccessToken الخاصة بـ Apigee.

التطبيق 1

• المنتج أ
• المنتج ب

التطبيق 2

• المنتج ب

التطبيق 3

• لا توجد منتجات (يمكن تحقيقها عن طريق الحذف عبر واجهة برمجة التطبيقات)

المنتج أ

• وكيل OAuth-ClientCredentials (لإنشاء الرمز المميز عبر مصادقة HTTP الأساسية)
• لا توجد مسارات الموارد

المنتج ب

• لا يوجد وكلاء API
• لا توجد مسارات الموارد

---

أسئلة

1. هل يتمتع APP 1 بإمكانية الوصول إلى جميع واجهات برمجة التطبيقات (المحمية وغير المحمية) بطبيعة الارتباط بالمنتج B؟
2. هل يتمتع التطبيق 2 بإمكانية الوصول إلى جميع واجهات برمجة التطبيقات (المحمية وغير المحمية)؟يتضمن هذا بشكل خاص الوصول إلى وكيل OAuth-ClientCredentials غير المدرج في أي من المنتجات.
3. هل يتمتع التطبيق 3 بإمكانية الوصول إلى جميع واجهات برمجة التطبيقات (المحمية وغير المحمية)؟

Answer 1

1. هل يتمتع APP 1 بإمكانية الوصول إلى جميع واجهات برمجة التطبيقات (المحمية وغير المحمية) بطبيعة الارتباط بالمنتج B؟
2. هل يتمتع التطبيق 2 بإمكانية الوصول إلى جميع واجهات برمجة التطبيقات (المحمية وغير المحمية)؟ويشمل ذلك بشكل ملحوظ الوصول إلى وكيل Oauth-Clientcredentials والذي لم يتم سرده في أي منتجات.
3. هل يتمتع التطبيق 3 بإمكانية الوصول إلى جميع واجهات برمجة التطبيقات (المحمية وغير المحمية)؟

الجواب على كل سؤال 3 هو نعم.

1. نعم -- لتسهيل إنشاء النماذج الأولية السريعة مع تكامل OAuth، لا يحتاج المطورون إلى إدراج/تحديث منتج باستخدام وكلاء واجهة برمجة التطبيقات (API) الجدد لتضمينه في نظام OAuth الخاص بـ Apigee.
2. نعم -- بأخذ اختبار التطبيق 1 خطوة أخرى إلى الأمام، فإن المنتج "أ" ليس مطلوبًا حتى للنماذج الأولية.
3. نعم - هذه حالة غير نمطية.لا تسمح واجهة المستخدم للمسؤول بحذف جميع المنتجات لتطبيق معين.سيحتاج المسؤول إلى الحذف عبر واجهة برمجة التطبيقات.

لاحظ أيضًا أنه بمجرد تضمين وكيل API واحد في المنتج، يتم قفل المنتج.وبعد ذلك، يقتصر الوصول على وكلاء واجهة برمجة التطبيقات المدرجة على وجه التحديد في هذا المنتج.