يوضّح هذا الدليل الاختلافات بين الإصدار 1 والإصدار 2 من Google Drive Activity API، وكيفية تغيير تطبيقك المتوافق مع الإصدار 1 لكي يتوافق مع الإصدار 2 من واجهة برمجة التطبيقات.
التفويض
استخدمت واجهة برمجة التطبيقات من الإصدار 1 النطاق التالي:
https://www.googleapis.com/auth/activity
تتطلّب واجهة برمجة التطبيقات v2 أحد النطاقات التالية:
https://www.googleapis.com/auth/drive.activityhttps://www.googleapis.com/auth/drive.activity.readonly
أسماء الموارد
في الإصدار 1 من واجهة برمجة التطبيقات، كانت معرّفات العناصر، مثل عناصر Google Drive والمستخدمين، سلاسل غير شفافة. في واجهة برمجة التطبيقات من الإصدار 2، تتم الإشارة عادةً إلى هذه العناصر باستخدام أسماء الموارد. لمزيد من المعلومات، يُرجى الاطّلاع على دليل تصميم واجهة برمجة تطبيقات Cloud API .
يمكن تحويل هذه المعرّفات بشكل عام. على سبيل المثال، تتم الإشارة إلى عناصر Drive
في واجهة برمجة التطبيقات v2 باستخدام اسم المورد
items/ITEM_ID_V1.
الطلبات
يشبه تنسيق الطلب في الإصدار 2 تنسيق الإصدار 1. على وجه التحديد، لا يزال بإمكانك
طلب نشاط لملف Drive أو ملف
أساسي في Drive، ولكن عليك تنسيق مَعلمات الطلب هذه على أنّها أسماء
موارد من خلال البادئة items/.
تم تغيير اسم "التجميع" إلى
التجميع، وتمّت إزالة مَعلمتَي الطلب source و
userId.
تتوفّر أيضًا خيارات فلترة جديدة تسمح لك بتقييد أنواع بيانات النشاط التي يتم عرضها في الاستجابة.
المهام
في الإصدار 1 من واجهة برمجة التطبيقات، كان نوع النشاط والبيانات المرتبطة به
في حقول منفصلة. على سبيل المثال، إذا كان حقل primaryEventType يحتوي على
القيمة move، ستفترض التطبيقات أنّه تمت تعبئة حقل move من المستوى الأعلى
بوالدَين تمت إضافتهما وإزالتهما.
في الإصدار 2 من واجهة برمجة التطبيقات، لم تعُد هذه الحقول متمايزة. تحتوي رسالة
ActionDetail
على حقل واحد فقط تم ضبطه. ويشير إلى نوع الإجراء ويحتوي على
التفاصيل المرتبطة بهذا الإجراء. على سبيل المثال، لا يضبط العنصر ActionDetail الذي يمثّل
عملية نقل سوى الحقل move، ويسرد هذا الحقل العناصر
الوالدة التي تمت إضافتها أو إزالتها.
يتطابق حقل primaryEventType في الإصدار 1 من واجهة برمجة التطبيقات تقريبًا مع الحقل
primaryActionDetail في الإصدار 2.
Actors
في الإصدار 1 من واجهة برمجة التطبيقات، كان النشاط المعروض يحتوي على User إذا كان الفاعل هو
مستخدم معروف، وكان يحتوي اختياريًا على حقل من المستوى الأعلى مثل fromUserDeletion للحالات
الخاصة.
في واجهة برمجة التطبيقات من الإصدار 2، تتوفّر مجموعة أكثر تنوعًا من
أنواع Actor، ويتم تعبئة user.knownUser عندما يكون الفاعل مستخدمًا معروفًا. إذا كان
تطبيقك بحاجة إلى معلومات مفصّلة عن المستخدمين، يمكنه طلبها من
People API من خلال تمرير الحقل KnownUser
personName إلى
طريقة people.get.
الأهداف
في الإصدار 1 من واجهة برمجة التطبيقات، كانت الاستهدافات دائمًا عناصر Drive. في الإصدار 2 من واجهة برمجة التطبيقات، يمكن أن تكون
الاستهدافات أنواعًا أخرى من العناصر في Drive. على سبيل المثال،
يكون للتغييرات التي تطرأ على مساحة تخزين نوع استهداف هو
Drive. لا يزال المجلد الجذر
لمساحة تخزين سحابي مشتركة يظهر (بصفته
DriveItem في حقل
root)، ولكنه ليس الهدف المباشر للنشاط. ينطبق مصطلح مماثل على موارد FileComment
التي يشير حقل parent فيها إلى ملف Drive الذي يحتوي على سلسلة المحادثات المستهدفة للتعليق.
النشاط المجمّع
في الإصدار 1 من واجهة برمجة التطبيقات، تغيّر أسلوب الردّ عند ضبط استراتيجية دمج (أو "تجميع").
على وجه التحديد، عند تفعيل الدمج، كان كلّ نشاط يحتوي على singleEvents المكوّن وcombinedEvent الذي يلخّص النشاط المشترَك بين هذه الأحداث المكوّنة. عندما كان الدمج
متوقفًا، كان الحقل combinedEvent يحتوي على الحدث
الأصلي غير المدمج لكل نشاط. يمكن أن يمثّل أيّ من هذه الأحداث أكثر من
إجراء واحد، مثل الإنشاء والمشاركة.
في الإصدار 2 من واجهة برمجة التطبيقات، لا يتغيّر أسلوب الاستجابة استنادًا إلى استراتيجية الدمج، لأنّ العنصر المُعاد
DriveActivity
يحتوي دائمًا على المجموعة الكاملة من الجهات الفاعلة والاستهدافات والإجراءات.