تؤدي مشاركة بيانات الاعتماد عبر طلبات واجهة برمجة التطبيقات إلى تحسين الأداء وتجنُّب النفقات الزائدة التي يمكن أن تؤدي إلى حدوث أخطاء متعلّقة بالحدّ الأقصى لمعدّل الزحف. يوضّح هذا الدليل كيفية تحسين إدارة بيانات اعتماد OAuth2 حتى يتمكّن تطبيقك من التفاعل بفعالية مع Google Ads API.
تعتمد استراتيجية مشاركة بيانات الاعتماد على ما إذا كان تطبيقك متعدد السلاسل أو متعدد العمليات (أو موزّعًا). إذا كان التطبيق متعدد العمليات ومتعدد السلاسل ضمن كل عملية، يجب أن يستخدم كلتا الاستراتيجيتين. يمكن أيضًا تعديل هذه الاستراتيجيات لتتناسب مع حسابات متعددة على "إعلانات Google".
متعدد السلاسل
ينبغي أن تستخدم كل جلسة أو مستخدم ترسمه سلسلة محادثات نفس كائن بيانات الاعتماد. يجب أيضًا إجراء عمليات تحديث رمز الدخول بشكل متزامن لتجنب حالات السباق.
وتضمن مكتبات العملاء لدينا أنّ بيانات الاعتماد هي كائن آمن لسلسلة المحادثات، ويعمل على تحديث نفسه بشكل متزامن عند انتهاء صلاحية رمز الدخول المميّز. لدى كل مكتبة من مكتبات العملاء لدينا كائن جلسة (أو مستخدم) مع بيانات اعتماد يعيد استخدامها
طوال عمره. لمشاركة بيانات الاعتماد عبر السلاسل، ما عليك سوى
إنشاء كل جلسة باستخدام نفس بيانات الاعتماد. على سبيل المثال، في مكتبة عملاء Java، يمكنك إنشاء Credential مفرد ومشاركته في جميع الجلسات.
عمليات متعددة أو موزّعة
بالنسبة للعمليات متعددة العمليات أو الموزعة، تحتاج إلى الاحتفاظ ببيانات الاعتماد قبل أن تتمكن من مشاركتها. لضمان عدم إجراء عمليات أو خوادم متعددة لتحديث بيانات الاعتماد في الوقت نفسه، ما يؤدي إلى زيادة عدد طلبات التحديث في الوقت نفسه، عليك تعيين عملية التحديث على عملية واحدة.
على سبيل المثال، يمكن أن تكون وظيفة أو خدمة منفصلة مسؤولة عن التحديث الدوري لبيانات الاعتماد ودفعها بشكل استباقي إلى مخزن بيانات تتم مشاركته بين مجموعة من الخوادم. يمكن لكل خادم بعد ذلك استرداد بيانات الاعتماد من مخزن البيانات عند تقديم طلب من واجهة برمجة التطبيقات.
إعادة تحميل المهمة
وينبغي ألا تنتظر مهمة التحديث إلى أن تنتهي صلاحية بيانات الاعتماد الحالية قبل بدء عملية التحديث. قد يؤدي ذلك إلى إيقاف التطبيق لعدم توفّر بيانات اعتماد صالحة، ومع ذلك، إذا انتهت صلاحية رمز الدخول الخاص ببيانات الاعتماد أثناء معالجة طلب واجهة برمجة التطبيقات، سيستمر إكمال الطلب وعرض النتائج.
ننصحك بتتبُّع الوقت الذي تمت فيه آخر عملية إعادة تحميل لرمز الدخول، وفرض إعادة التحميل إذا كانت هناك أقل من 5 دقائق حتى انتهاء الصلاحية.
إذا كنت لا تعرف تاريخ آخر تحديث لرمز الدخول، يمكنك محاولة إعادة تحديثه بافتراض انتهاء صلاحيته. وإذا لم يكن رمز الدخول قريبًا من البداية، فإن الخادم يعرض رمز الدخول نفسه مع بقاء المللي ثانية المتبقية حتى انتهاء صلاحية الرمز.
مخزن البيانات
يمكنك الاستفادة من مخزن بيانات حالي أو نشر مخزن بيانات خاص بمشاركة بيانات الاعتماد بين الخوادم. وتشمل الحلول خوادم التخزين المؤقت، مثل Memcached أو Infinispan، أو مخازن بيانات NoSQL، مثل MongoDB.
يجب تحسين مخزن البيانات لعمليات القراءة السريعة حيث سيكون هناك العديد من طلبات القراءة أكثر من عمليات الكتابة. ويجب تخزين بيانات الاعتماد بأمان.
عند تخزين بيانات الاعتماد، يجب تخزين قيمتَي expiry_time المحسوبة
(الآن + expires_in) وrefresh_token مع access_token. يتم احتساب
expiry_time كوقت طلب إعادة تحميل access_token
بالإضافة إلى وقت expires_in.
مجموعة الخوادم
ويسترد كل خادم أو عملية في المجموعة أحدث بيانات اعتماد من مخزن البيانات قبل تقديم طلب. وما دامت مهمة التحديث تعمل بشكل صحيح، ستكون الاعتمادات صالحة. ومع ذلك، إذا فشلت مهمة التحديث أو مخزن البيانات، فيجب أن تكون لديك آلية احتياطية.
إذا تعذّر على الخادم أو العملية الحصول على بيانات اعتماد من مخزن البيانات، أو إذا انتهت صلاحية بيانات الاعتماد، على الخادم تحديث بيانات الاعتماد الخاصة به للسماح للتطبيق بمواصلة العمل باستخدام واجهة برمجة التطبيقات إلى أن يتم حل المشكلة.
إدارة بيانات الاعتماد لحسابات متعددة
يمكن استخدام بيانات الاعتماد التي تم إنشاؤها لحساب إداري على "إعلانات Google" للوصول إلى جميع حساباته الفرعية. وبالتالي، بالنسبة إلى المستخدِمين الذين لديهم هيكل هرمي واحد لحساب إداري، عادةً ما يكفي إنشاء بيانات اعتماد للحساب الإداري ذي المستوى الأعلى حتى يتم استخدامها لجميع حسابات "إعلانات Google" المندرجة ضمنه.
إذا كان تطبيقك يحتاج إلى الوصول إلى حسابات "إعلانات Google" غير مرتبطة ببعضها البعض في أي تسلسل هرمي للحسابات الإدارية، عليك إنشاء بيانات اعتماد مختلفة والاحتفاظ بها للحسابات المختلفة، مثل كل حساب عميل تصل إليه على "إعلانات Google"، أو لكل حساب إداري على مستوى أعلى في التسلسلات الهرمية المستقلة التي تصل إليها.
يمكنك اتّباع الاستراتيجيات نفسها للتطبيقات المتعدّدة سلاسل المحادثات أو متعددة العمليات / الموزعة مع إجراء تعديلات طفيفة. عند
استخدام مخزن بيانات مشترك، يجب فهرسة بيانات الاعتماد باستخدام معرّف الحساب
customerId لضمان ربط بيانات الاعتماد بالحساب الصحيح.
بالإضافة إلى ذلك، يجب إعادة تحميل جميع بيانات الاعتماد في مهمة إعادة التحميل. في حال ربط حساب جديد، قد تحتاج إلى تشغيل مهمة إعادة التحميل.
أخيرًا، في التطبيقات المتعددة السلاسل، يجب عليك فقط مشاركة كائن بيانات الاعتماد عبر سلاسل المحادثات التي تعمل على الحساب الذي يرتبط به كائن بيانات الاعتماد.