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

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

إذا كنت تريد مواصلة استخدام الإصدار 2، يُرجى الاطّلاع على التعديل في دليل استخدام واجهة برمجة التطبيقات v2 للتعرّف على طريقة استخدام بعض التعليمات في الإصدار الثالث. الأدلة بتعديل v2 لمطوّري البرامج.

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

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

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

• لا تعرض عمليات البحث عن الملفات ومساحات التخزين السحابي المشتركة موارد كاملة تلقائيًا، لن يتم إرجاع سوى مجموعة فرعية من الحقول شائعة الاستخدام. لمزيد من التفاصيل عن fields، اطّلِع على طريقة files.list. وطريقة drives.list.
• إنّ جميع الطرق التي تعرض ردًّا تقريبًا الآن تتطلّب fields. . للحصول على قائمة بجميع الطرق التي تتطلّب fields، يُرجى مراجعة مرجع واجهة برمجة تطبيقات Drive
• تمت إزالة الموارد التي تحتوي على إمكانات مكرّرة. في ما يلي بعض الأمثلة:
  • تؤدي الطريقة 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.
• تؤدي طُرق التعديل الآن إلى رفض الطلبات التي تحدّد حقولاً غير قابلة للكتابة.
• حقلا الإصدار 2 exportFormats وimportFormats في مورد about عبارة عن قوائم تنسيقات الاستيراد أو التصدير المسموح بها. في الإصدار 3، تعد خرائط من نوع MIME الاستهدافات المحتملة لجميع عمليات الاستيراد أو التصدير المسموح بها.
• أصبح الاسمان البديلان للبريد الإلكتروني v2 appdata وappfolder هما الآن 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).