التفويض
يجب أن يوافق مستخدم مصادَق عليه على كلّ الطلبات الموجّهة إلى واجهة برمجة التطبيقات Google Photos Library API.
تختلف تفاصيل عملية التفويض لبروتوكول OAuth 2.0 قليلاً حسب حول نوع التطبيق الذي تكتبه. العملية العامة التالية ينطبق على جميع أنواع التطبيقات:
- استعد لعملية التفويض من خلال القيام بما يلي:
- سجّل تطبيقك باستخدام وحدة التحكم في واجهة Google API:
- تفعيل واجهة برمجة التطبيقات للمكتبة واسترداد تفاصيل OAuth مثل معرف العميل وسر العميل. لمزيد من المعلومات، يُرجى مراجعة البدء
- للوصول إلى بيانات المستخدمين، يطلب التطبيق إلى Google نطاق وصول معين.
- تعرض Google شاشة موافقة للمستخدم تطلب منه السماح بما يلي: التطبيق لطلب بعض بياناته.
- إذا وافق المستخدم، ستوفّر Google للتطبيق رمز الدخول. تنتهي صلاحيتها بعد فترة زمنية قصيرة.
- يطلب التطبيق الحصول على بيانات المستخدمين، ويرفق رمز الدخول. بالطلب.
- وإذا حددت Google أن الطلب والرمز المميز صالحين، فسيعرض البيانات المطلوبة.
لتحديد النطاقات المناسبة لتطبيقك، يُرجى الاطّلاع على مقالة منح الأذونات. والنطاقات.
تتضمن العملية المتعلقة ببعض أنواع التطبيقات خطوات إضافية، مثل استخدام تحديث الرموز المميزة للحصول على رموز دخول جديدة. للحصول على معلومات تفصيلية حول لأنواع مختلفة من التطبيقات، راجع استخدام OAuth 2.0 للدخول إلى Google API.
التخزين المؤقت
حافظ على حداثة البيانات.
إذا كنت بحاجة إلى تخزين الوسائط مؤقتًا (مثل الصور المصغّرة أو الصور أو الفيديوهات) لأسباب تتعلق بالأداء، لا تخزّنه مؤقتًا لأكثر من 60 دقيقة حسب استخدامنا إرشاداتنا.
لا يُنصح أيضًا بتخزين baseUrls، إذ تنتهي صلاحيته بعد 60 تقريبًا.
دقيقة.
معرّفات عناصر الوسائط ومعرّفات الألبومات التي تعرّف المحتوى في مكتبة المستخدم بشكل فريد معفاة من قيود التخزين المؤقت. يمكنك تخزين أرقام التعريف هذه لأجل غير مسمى (يخضع لسياسة خصوصية طلبك). استخدام معرّفات عناصر الوسائط ومعرّفات الألبومات لاسترداد عناوين URL والبيانات التي يمكن الوصول إليها مرة أخرى باستخدام نقاط النهاية المناسبة. بالنسبة الحصول على مزيد من المعلومات، يُرجى الاطّلاع على الحصول على وسائط عنصر أو قائمة الألبومات.
إذا كان لديك العديد من عناصر الوسائط لإعادة تحميلها، فقد يكون من الأفضل تخزين ملف مَعلمات البحث التي عرضت ملفات الوسائط وإعادة إرسال طلب البحث لإعادة التحميل البيانات.
الوصول إلى طبقة المقابس الآمنة
يجب توفُّر HTTPS لجميع طلبات خدمة الويب من واجهة برمجة تطبيقات المكتبة التي تستخدم عنوان URL التالي:
https://photoslibrary.googleapis.com/v1/service/output?parameters
يتم رفض الطلبات المقدَّمة عبر HTTP.
خطأ أثناء المعالجة
لمزيد من المعلومات حول كيفية التعامل مع الأخطاء الناتجة عن واجهة برمجة التطبيقات، يمكنك الاطّلاع على التعامل مع واجهات برمجة التطبيقات الأخطاء.
إعادة محاولة تقديم الطلبات التي تعذّر تنفيذها
على العملاء إعادة المحاولة بشأن أخطاء 5xx مع رقود أسي كما هو موضّح في
رقود أسي: يجب أن يكون الحد الأدنى للمهلة 1 s.
ما لم يتم توثيق خلاف ذلك.
بالنسبة إلى أخطاء 429، قد يعيد البرنامج المحاولة بعد مهلة 30s على الأقل. لجميع التطبيقات الأخرى
من الأخطاء، فقد لا يكون بالإمكان إعادة المحاولة. يُرجى التأكد من عدم تطابق الطلب مع
رسالة الخطأ للحصول على الإرشادات.
تراجع أسي
في حالات نادرة، قد يحدث خطأ أثناء عرض طلبك.وقد تتلقى
رمز استجابة HTTP 4XX أو 5XX، أو قد يتعذّر اتصال TCP في مكان ما
بين عميلك وخادم Google. وفي كثير من الأحيان، من الجدير إعادة محاولة
طلبك. قد ينجح طلب المتابعة عند تعذُّر إرسال الطلب الأصلي. ومع ذلك،
من المهم عدم التكرار الحلقي، وتقديم الطلبات إلى خوادم Google بشكل متكرر. هذا النمط
يمكن أن يؤدي هذا السلوك إلى زيادة الحمل على الشبكة بين العميل وGoogle
وتسبب مشاكل للعديد من الأطراف.
الطريقة الأفضل هي إعادة المحاولة مع زيادة التأخيرات بين المحاولات. عادةً، يزداد التأخير باستخدام عامل مضاعف مع كل محاولة، والمعروفة باسم أسي تراجع.
يجب توخي الحذر أيضًا من عدم إعادة محاولة استخدام الرمز في مستوى أعلى في التطبيق. سلسلة اتصال تؤدي إلى تكرار الطلبات في تتابع سريع.
استخدام مهذب لـ Google APIs
يمكن لعملاء واجهة برمجة التطبيقات ذوي التصميم السيئ وضع حمل أكبر من اللازم على كلٍ من الإنترنت وعلى خوادم Google. يحتوي هذا القسم على بعض أفضل الممارسات لعملاء واجهات برمجة التطبيقات. يمكن أن يساعدك اتباع أفضل الممارسات هذه في تجنب تم حظر تطبيق بسبب إساءة استخدام واجهات برمجة التطبيقات عن غير قصد.
الطلبات المتزامنة
قد تبدو الأعداد الكبيرة من الطلبات المتزامنة إلى واجهات برمجة تطبيقات Google هجمة موزّعة لحجب الخدمة (DDoS) على بنية Google الأساسية تتم معاملته وفقًا لذلك. ولتجنُّب حدوث ذلك، عليك التأكّد من تنفيذ طلبات البيانات من واجهة برمجة التطبيقات غير متزامن بين العملاء.
على سبيل المثال، ضع في اعتبارك تطبيقًا يعرض الوقت في الوقت الحالي المنطقة. من المحتمل أن يضبط هذا التطبيق تنبيهًا في نظام تشغيل العميل وتوقظه في بداية الدقيقة بحيث يمكن تحديد الوقت المعروض تحديث. يجب ألا يُجري التطبيق أي طلبات بيانات من واجهة برمجة التطبيقات كجزء من عملية المعالجة. المرتبط بهذا المنبّه.
يُعد إجراء طلبات بيانات من واجهة برمجة التطبيقات ردًا على إنذار تم إصلاحه أمرًا سيئًا لأنه يؤدي إلى تتم مزامنة طلبات البيانات من واجهة برمجة التطبيقات مع بداية الدقيقة، حتى بين بدلاً من توزيعها بالتساوي مع مرور الوقت. مصمم سيئ نتجت عن ذلك ارتفاعًا كبيرًا في حركة الزيارات على المستويات العادية ستين ضعفًا في بداية كل دقيقة.
بدلاً من ذلك، هناك تصميم جيد محتمل وهو ضبط منبّه ثانٍ على الوقت الذي اخترته. عند تنشيط هذا الإنذار الثاني، يُجري التطبيق مكالمات إلى واجهات برمجة التطبيقات التي تحتاج إليها وتخزن النتائج. لتحديث شاشة العرض في بداية يستخدم التطبيق النتائج المخزنة مسبقًا بدلاً من استدعاء API مرة أخرى. ومن خلال هذا النهج، يتم توزيع طلبات البيانات من واجهة برمجة التطبيقات بالتساوي على مدار الوقت. كذلك، لا تؤخر طلبات البيانات من واجهة برمجة التطبيقات العرض عند تحديث الشاشة.
وبغض النظر عن بداية تلك اللحظة، هناك أوقات مزامنة شائعة أخرى ينبغي أن يحرص على عدم الاستهداف في بداية ساعة وبداية كل يوم في منتصف الليل.