نقل البيانات من الإصدار 1 من واجهة برمجة تطبيقات النشاط في Drive

يشرح هذا الدليل أوجه الاختلاف بين الإصدار 1 و2 من واجهة برمجة تطبيقات النشاط في Google Drive، وكيفية تغيير تطبيقك v1 ليتوافق مع الإصدار v2 API.

التفويض

استخدمت واجهة برمجة التطبيقات v1 هذا النطاق:

  • https://www.googleapis.com/auth/activity

تتطلب واجهة برمجة التطبيقات v2 أحد النطاقات التالية:

  • https://www.googleapis.com/auth/drive.activity
  • https://www.googleapis.com/auth/drive.activity.readonly

أسماء الموارد

في الإصدار 1 من واجهة برمجة التطبيقات، كانت معرّفات كائنات مثل عناصر Google Drive والمستخدمين سلاسل مبهمة. في الإصدار 2 من واجهة برمجة التطبيقات، تتم عادةً الإشارة إلى هذه الكائنات باستخدام أسماء الموارد. لمزيد من المعلومات، يُرجى الاطّلاع على دليل تصميم Cloud API .

ويمكن تحويل هذه المعرّفات بشكل عام. على سبيل المثال، تتم الإشارة إلى عناصر Drive في v2 API باستخدام اسم المورد items/ITEM_ID_V1.

الكائن Requests

ويكون تنسيق الطلب الخاص بالإصدار 2 مشابهًا لتنسيق الطلب الخاص بالإصدار 1. وعلى وجه التحديد، لا يزال بإمكانك طلب نشاط لملف Drive أو أحد أصل Drive، على الرغم من أنه يجب تنسيق معلَمات الطلب هذه باعتبارها أسماء موارد، وذلك من خلال استهلالها بـ items/.

تغيّر اسم "التجميع" إلى الدمج، وتمّت إزالة معلَمتَي الطلب source وuserId.

هناك أيضًا خيارات فلترة جديدة تسمح لك بتقييد أنواع بيانات النشاط التي يتم عرضها في الاستجابة.

المهام

في الإصدار 1 من واجهة برمجة التطبيقات، كان نوع النشاط والبيانات المرتبطة بهذا النشاط في حقول منفصلة. على سبيل المثال، إذا كان الحقل primaryEventType يحتوي على القيمة move، ستفترض التطبيقات أنّه تتم تعبئة حقل move ذي المستوى الأعلى بالقيمتين الرئيسيتين اللتين تمت إضافتهما أو إزالتهما.

في الإصدار 2 من واجهة برمجة التطبيقات، لم تعُد هذه الحقول مختلفة. تحتوي رسالة ActionDetail على حقل واحد فقط. تشير إلى نوع الإجراء ويحتوي على التفاصيل المرتبطة بهذا الإجراء. على سبيل المثال، يؤدي ActionDetail الذي يمثّل عملية نقل إلى ضبط الحقل move فقط، ويدرج هذا الحقل العناصر الرئيسية التي تمت إضافتها أو إزالتها.

ويتطابق حقل primaryEventType لواجهة برمجة التطبيقات الإصدار 1 تقريبًا مع حقل الإصدار 2 primaryActionDetail.

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 التي يتم عرضها تحتوي دائمًا على المجموعة الكاملة من الممثلين والأهداف والإجراءات.