ORCID يهدف إلى دعم إصدارين رئيسيين لواجهة برمجة التطبيقات في وقت واحد. عندما يتم إصدار إصدار رئيسي جديد لواجهة برمجة التطبيقات ، ORCID يضمن الدعم لمدة ثلاث سنوات على الأقل من تاريخ الإصدار. بالإضافة إلى ذلك ، نقدم إشعارًا لمدة 12 شهرًا قبل تقاعد أقدم إصدار رئيسي ، ونرسل رسائل تذكير دورية عبر البريد الإلكتروني إلى الأعضاء الذين ما زالوا يستخدمونها خلال فترة الإخطار. تكون الإصدارات الرئيسية الجديدة مطلوبة عندما نجري تغييرات مفاجئة على مخطط البيانات الوصفية ويتم الإشارة إليها بزيادة رقم الإصدار الرئيسي. ORCID تطلق إصدارًا رئيسيًا جديدًا لواجهة برمجة التطبيقات كل 2-4 سنوات.
في ظروف استثنائية ، ORCID قد تفكر في تمديد فترة التقاعد التي تبلغ 12 شهرًا عند إصدار إصدار رئيسي جديد لواجهة برمجة التطبيقات ، ولكن هذا يتطلب ORCID لاستثمار موارد إضافية في أعمال الصيانة ، مع ما يترتب على ذلك من تأثير على الأنشطة الأخرى مثل التطوير والدعم الجديدين. ORCID تحتفظ لنفسها بالحق في فرض رسوم إضافية على الاستخدام المتواصل لنسخة API منتهية الصلاحية بعد تاريخ التقاعد من أجل المساعدة في تعويض التكاليف الإضافية المتكبدة.
ORCID لديه سياسة إبطال تدريجية لواجهة برمجة التطبيقات تتيح لنا تطوير عروض API لدينا والاستجابة لاحتياجات المجتمع بين الإصدارات الرئيسية. هذا يعني ذاك ORCID إجراء تغييرات غير منقطعة على المفردات وحقول البيانات الوصفية التي يتم التحكم فيها لإصدار واجهة برمجة التطبيقات الحالية.
- يتمتع مستخدمو أحدث إصدار من واجهة برمجة التطبيقات بحرية تجاهل هذه التغييرات ، ولكن يجب أن يدركوا أنه يمكن إجراؤها
- لن يتلقى مستخدمو إصدار API السابق بيانات لا يمكن نمذجتها في نسختهم
مثال في وقت كتابة هذا التقرير هو تقديم تصنيف دور مساهم CREDIT في v3.0 API. بمجرد البث المباشر ، ستفقد تكاملات الإصدار 2.x ببطء رؤية أدوار المساهمين حيث يتبنى المزيد والمزيد من الباحثين وعمليات الدمج CREDIT. لن ينكسر مستخدمو الإصدار 2.x ، لكنهم سيحصلون على بيانات وصفية أقل ثراءً مع مرور الوقت.
عند تطوير إصدار رئيسي جديد لواجهة برمجة التطبيقات ، فمن الطبيعي أن يكون ORCID لإنتاج إصدارات "الإصدار المرشحة". هذه موجهة للمتكاملين القادرين على الترقية في الوقت المناسب بمجرد إصدار الإصدار الكامل من API. العمر المتوقع للإصدار المرشح هو 12 شهرًا على الأكثر من إصدار الإصدار الرئيسي الذي تم تطويره من أجله.
ننصح شركات التكامل باتباع مبدأ المتانة (المعروف أيضًا باسم قانون Postel) عند استخدام امتداد ORCID API.
خلفيّة
ORCID لقد تطور ببطء API الخاص به من بداياته المتواضعة.
حاول API v1.x (Launch ~ 2012 مع السجل) إرجاع جميع البيانات الوصفية حول الباحثين وأنشطتهم في استجابة واحدة لواجهة برمجة التطبيقات. طُلب من المندمجين تعديل هذه البيانات الوصفية وإرسالها مرة أخرى بالكامل من أجل إضافة عناصر جديدة أو تحديث العناصر الموجودة. كانت هذه المحاولة الأولى المعقولة ، لكنها لم تتسع ، وكان إجراء الإضافات والتحديثات مهمة شاقة. (تقاعد في مارس 2018)
API 2.x (تم إصداره في فبراير 2017) قسم API الخاص بنا إلى أقسام ؛ الأعمال ، والانتسابات ، والتمويل ، والسيرة الذاتية ، إلخ. لقد كانت خطوة كبيرة إلى الأمام ومكنت أنفسنا وعملائنا من إدارة السجلات الكبيرة بشكل أسهل. ومع ذلك ، فإن الكثير من التحقق من صحة المفردات والتحكم فيها كانت مشفرة بشدة في المخطط ، مما يجعل من الصعب الاستجابة للتغيير
أضاف API 3.x (تم إصداره في مايو 2019) أقسامًا جديدة إلى السجل مثل موارد البحث وتبسيط بنية المخطط وتوفيرها ORCID بمرونة إضافية. لقد نقل الكثير من التحقق من صحة المخطط إلى خوادمنا ، مما مكننا من إصلاح المشكلات وإضافة أنواع معرفات جديدة دون إصدار إصدارات أخرى من واجهة برمجة التطبيقات.
يعد إصدار واجهة برمجة تطبيقات رئيسية جديدة مهمة ضخمة - يلزم سنوات من جهود المطورين لإنشائها ، ويحتاج أعضاؤنا إلى سنوات أخرى لترقية عمليات التكامل الخاصة بهم. لهذا السبب نحاول الحد من التغييرات التي نجريها. ومع ذلك ، هناك بعض التغييرات التي نرغب في إجرائها لخدمة المجتمع بشكل أفضل.
مهمتنا هي العمل عندما يكون لدينا كتلة حرجة لإصدار نسخة جديدة من API ، أو العمل على إيجاد طرق لتحديث واجهات برمجة التطبيقات الحالية لدينا دون كسر عمليات الدمج الحالية.