تطبيق أفضل الممارسات على Microsoft Graph
توضح هذه الوحدة أفضل الممارسات التي يمكنك تطبيقها لتحقيق أقصى استفادة من Microsoft Graph وجعل تطبيقك أكثر موثوقية للمستخدمين النهائيين.
المصادقة
للوصول إلى البيانات في Microsoft Graph، يحتاج تطبيقك إلى الحصول على رمز وصول OAuth 2.0، ويقدمه إلى Microsoft Graph بأي من الطرق التالية:
- رأس طلب "HTTP" التخويل كرمز حامل
- منشئ عميل الرسم البياني عند استخدام مكتبة عميل Microsoft Graph
استخدمMicrosoft Authentication Library API ،MSAL للحصول على رمز الوصول إلى Microsoft Graph.
الموافقة والتخويل
تطبيق أفضل الممارسات التالية للحصول على الموافقة والتخويل في التطبيق الخاص بك:
استخدام الامتياز الأقل. اطلب فقط الأذونات الضرورية، وعندما تحتاج إليها فقط. بالنسبة لواجهات برمجة التطبيقات، يتحقق تطبيقك من قسم الأذونات في مواضيع الأسلوب. على سبيل المثال، راجع إنشاء مستخدم وحدد الأذونات الأقل تميزاً.
استخدم نوع الإذن الصحيح استناداً إلى وحدات السيناريو. إذا كنت تقوم بإنشاء تطبيق تفاعلي حيث يوجد مستخدم مسجل الدخول، فيجب أن يستخدم التطبيق الأذونات المفوضة. ومع ذلك، إذا كان التطبيق الخاص بك يعمل دون مستخدم تسجيل الدخول، مثل خدمة خلفية أو برنامج الخفي، يجب أن يستخدم التطبيق أذونات التطبيق.
تنبيه
استخدام أذونات التطبيق للسيناريوهات التفاعلية يمكن أن يضع التطبيق الخاص بك في خطر التوافق والأمان. تأكد من التحقق من امتيازات المستخدم للتأكد من عدم وجود وصول غير مرغوب فيه إلى المعلومات، أو أنه يقوم بالإبحار حول السياسات التي تم تكوينها من قبل مسؤول.
النظر في تجربة المستخدم النهائي والمشرف. يؤثر مباشرة على تجارب المستخدم والمسؤول. على سبيل المثال:
ضع في اعتبارك من يوافق على التطبيق الخاص بك، سواء المستخدمين النهائيين أو المسؤولين، وقم بتكوين التطبيق الخاص بك لطلب الأذونات بشكل مناسب.
تأكد من فهم الفرق بين الموافقة الثابتة والديناميكية والتزايدية.
النظر في التطبيقات متعددة المستأجرين. توقع أن يكون لدى العملاء عناصر تحكم مختلفة للتطبيق والموافقة في ولايات مختلفة. على سبيل المثال:
يمكن لمسؤولي المستأجر تعطيل قدرة المستخدمين النهائيين على الموافقة على التطبيقات. في هذه الحالة، يحتاج المسؤول إلى الموافقة نيابة عن مستخدميه.
يمكن لمسؤولي المستأجرين تعيين نهج المصادقة المخصصة مثل منع المستخدمين من قراءة ملفات تعريف المستخدمين الآخرين، أو الحد من إنشاء مجموعة الخدمة الذاتية على مجموعة محدودة من المستخدمين. في هذه الحالة، يجب أن يتوقع تطبيقك معالجة استجابة الخطأ 403 عند التصرف نيابة عن المستخدم.
التعامل مع الاستجابات بفعالية
استناداً إلى الطلبات التي تقوم بها إلى Microsoft Graph، يجب أن تكون التطبيقات الخاصة بك جاهزة للتعامل مع أنواع مختلفة من الاستجابات. فيما يلي بعض من أهم الممارسات التي يجب اتباعها لضمان أن التطبيق الخاص بك يتصرف بشكل موثوق ومتوقع للمستخدمين النهائيين. على سبيل المثال:
ترقيم الصفحات: عند الاستعلام عن مجموعات الموارد، يجب أن تتوقع أن يقوم Microsoft Graph بإرجاع مجموعة النتائج في صفحات متعددة، بسبب حدود حجم الصفحة من جانب الخادم. يجب أن يتعامل تطبيقك دائما مع إمكانية أن تتم صفحات الاستجابات بطبيعتها، واستخدام
@odata.nextLinkالخاصية للحصول على مجموعة النتائج التالية المصفحة، حتى تتم قراءة جميع صفحات مجموعة النتائج. لا تتضمن الصفحة الأخيرة خاصية@odata.nextLink. لمزيد من المعلومات، تفضل بزيارة ترحيل الصفحات.عمليات التعداد القابلة للتطور: يمكن أن تؤدي إضافة أعضاء إلى التعدادات الموجودة إلى تعطيل التطبيقات التي تستخدم هذه التعدادات بالفعل. التعدادات القابلة للتطوير هي آلية تستخدمها واجهة برمجة تطبيقات Microsoft Graph لإضافة أعضاء جدد إلى التعدادات الموجودة دون التسبب في تغيير فاصل للتطبيقات. بشكل افتراضي، تقوم عملية GET بإرجاع الأعضاء المعروفين فقط لخصائص أنواع القيمة القابلة للتطور ويحتاج التطبيق الخاص بك إلى معالجة الأعضاء المعروفين فقط. إذا قمت بتصميم التطبيق الخاص بك للتعامل مع الأعضاء غير المعروفين أيضا، يمكنك الاشتراك في تلقي هؤلاء الأعضاء باستخدام عنوان طلب HTTP
Prefer.
تخزين البيانات محلياً
من المفترض أن يقوم التطبيق الخاص بك بإجراء مكالمات إلى Microsoft Graph لاسترداد البيانات في الوقت الفعلي حسب الضرورة. يجب تخزين البيانات الضرورية محليا لسيناريو معين أو تخزينها فقط. إذا كانت حالة الاستخدام هذه مشمولة بشروط الاستخدام ونهج الخصوصية، ولا تنتهك شروط استخدام واجهات برمجة تطبيقات Microsoft، فيجب على تطبيقك أيضا تنفيذ نهج الاستبقاء والحذف المناسبة.