دليل المقارنة بين الإصدارين 2 و3 من واجهة برمجة تطبيقات Drive

أحدث إصدار من Google Drive API هو الإصدار 3. يكون الأداء في الإصدار 3 أفضل لأنّه لا تعرض عمليات البحث سوى مجموعة فرعية من الحقول. استخدِم الإصدار الحالي ما لم تكن بحاجة إلى مجموعة v2. إذا كنت تستخدم الإصدار 2، ننصحك بالترقية إلى الإصدار 3. لنقل البيانات، يُرجى الاطّلاع على مقالة نقل البيانات إلى الإصدار 3 من Drive API. للحصول على قائمة كاملة بالاختلافات بين الإصدارَين، يُرجى الاطّلاع على مرجع مقارنة الإصدارَين 2 و3 من Drive API.

إذا أردت مواصلة استخدام الإصدار 2، اطّلِع على تعديل دليل الإصدار 2 من Drive API لمعرفة كيفية تعديل بعض التعليمات في أدلة الإصدار 3 لمطوّري الإصدار 2.

للاطّلاع على مزيد من المعلومات حول تحسينات الإصدار 3 من Drive API، يمكنك مشاهدة الفيديو التالي الذي يعرض مهندسو Google تصميم واجهة برمجة التطبيقات الجديدة.

تحسينات الإصدار 3

لتحسين الأداء وتقليل تعقيد سلوك واجهة برمجة التطبيقات، يقدّم الإصدار 3 تحسينات التالية مقارنةً بالإصدار السابق من واجهة برمجة التطبيقات:

• لا تؤدي عمليات البحث عن الملفات ومساحات التخزين السحابي المشتركة إلى عرض الموارد الكاملة تلقائيًا، بل يتم عرض مجموعة فرعية فقط من الحقول المستخدَمة بشكل شائع. لمزيد من التفاصيل حول fields، اطّلِع على طريقة files.list وطريقة drives.list.
• تتطلّب الآن جميع الطرق تقريبًا التي تعرض ردًا مَعلمة fields. للحصول على قائمة بجميع الطرق التي تتطلّب fields، يُرجى الاطّلاع على مرجع Drive API.
• تمت إزالة الموارد التي تتضمّن إمكانات مكرّرة. في ما يلي بعض الأمثلة:
  • تؤدي طريقة files.list الوظيفة نفسها التي تؤديها مجموعتا Children وParents، لذا تمت إزالتهما من الإصدار 3.
  • تمّت إزالة طرق Realtime.*.
• لا يتم عرض "بيانات التطبيق" تلقائيًا في عمليات البحث. في الإصدار 2، يمكنك ضبط نطاق drive.appdata، وسيعرض بيانات التطبيق من files.list وchanges.list ، ولكنّه يبطئ الأداء. في الإصدار 3، يمكنك ضبط نطاق drive.appdata، وضبط مَعلمة الطلب spaces=appDataFolder أيضًا لطلب بيانات التطبيق.
• تستخدم جميع عمليات التعديل PATCH بدلاً من PUT.
• لتصدير "مستندات Google"، استخدِم الطريقة files.export.
• يختلف سلوك الطريقة changes.list. بدلاً من تغيير المعرّفات، استخدِم رموز صفحات غير شفافة. لفحص مجموعة التغييرات، عليك أولاً استدعاء الأسلوب changes.getStartPageToken للقيمة الأولية. بالنسبة إلى طلبات البحث اللاحقة، تُرجع الطريقة changes.list القيمة newStartPageToken.
• ترفض طرق التعديل الآن الطلبات التي تحدّد حقولًا غير قابلة للكتابة.
• حقلَا exportFormats وimportFormats في الإصدار 2 من موارد about هما قائمتان بملفَي التنسيق المسموح بهما للاستيراد أو التصدير. في الإصدار 3، تكون هذه الخرائط عبارة عن خرائط لأنواع MIME لتحديد الاستهدافات المحتمَلة لجميع عمليات الاستيراد أو التصدير المتوافقة.
• أصبحت الأسماء البديلة appdata وappfolder في الإصدار 2 هي appDataFolder في الإصدار 3.
• تمت إزالة المورد properties من الإصدار 3. يحتوي المورد files على الحقل properties الذي يحتوي على أزواج مفاتيح وقيم صحيحة. يحتوي الحقل properties على خصائص علنية، ويحتوي الحقل appProperties على خصائص خاصة، لذلك لا حاجة إلى حقل مستوى الرؤية.
• يتم تعديل الحقل modifiedTime في مورد files في آخر مرة عدَّل أي مستخدم الملف. في الإصدار 2، كان حقل modifiedDate قابلاً للتغيير فقط عند التحديث إذا تم ضبط حقل setModifiedDate.
• لا يتم تعديل الحقل viewedByMeTime في مورد files تلقائيًا.
• لاستيراد تنسيقات "مستندات Google"، عليك ضبط الوجهة المناسبة mimeType في نصّ المورد. في الإصدار 2، يمكنك ضبط ?convert=true.
• تُعرِض عمليات الاستيراد خطأ 400 إذا لم يكن التنسيق متوافقًا.
• لا يمكن للقارئين والمعلقين الاطّلاع على الأذونات.
• تمت إزالة الاسم المعرِّف me للأذونات.
• كانت بعض الوظائف متاحة كجزء من مورد الطلب، ولكنها متوفّرة الآن كمَعلمة طلب. على سبيل المثال:
  • في الإصدار 2، يمكنك استخدام children.delete لإزالة ملف فرعي من مجلد رئيسي.
  • في الإصدار 3، يمكنك استخدامfiles.update في حساب الطفل مع ?removeParents=parent_id في عنوان URL.

الاختلافات الأخرى

تختلف أسماء الحقول والمَعلمات في الإصدار 3. ومن الأمثلة على ذلك:

• يحلّ الموقع name محلّ title في المرجع files.
• Time هي اللاحقة لجميع حقول التاريخ والوقت بدلاً من Date.
• لا تستخدِم عمليات القائمة حقل items لاحتواء مجموعة النتائج. يقدّم نوع المورد حقلًا للنتائج (مثل files أو changes).