في هذه المقابلة روب بيترز ، ORCIDمدير التكنولوجيا ، يقدم ORCIDواجهة برمجة التطبيقات الجديدة - تم إطلاقها في 14 فبراير 2017
قبل أن نبدأ الحديث عن واجهة برمجة التطبيقات الجديدة ، هل يمكنك إخبارنا قليلاً عنها ORCIDالفريق الفني ودورك كمدير؟
للوهلة الأولى ، فإن ORCID الفريق يشبه إلى حد كبير أي فريق تقني آخر. لدينا خمسة مطورين ومسؤول خادم ومحلل ضمان جودة وبالطبع مدير (أنا). ومع ذلك ، حيث يصبح الأمر مثيرًا للاهتمام هو خلفياتنا الجغرافية والثقافية والعملية المختلفة. ثلاثة منا في الولايات المتحدة ، وثلاثة في كوستاريكا ، واثنان في المملكة المتحدة ، لذلك نحصل على الكثير من المنظور الجغرافي. بالإضافة إلى ذلك ، يأتي بعضنا من استشارات البرامج التقليدية ، ويأتي البعض الآخر من صناعة النشر ، وشركات "وادي السيليكون" الناشئة ، وعلوم المكتبات.
دوري الشخصي كمدير للتكنولوجيا هو إدارة تطوير البرمجيات اليومية. يتلخص ذلك في مساعدة فريقي على التواصل مع بعضهم البعض وبقية المنظمة ، بالإضافة إلى إدارة المهام التي يتولاها الفريق (والتي يتم تأجيلها). كما أتيحت لي الفرصة للحصول على الكثير من المدخلات بشأن القرارات الإستراتيجية عالية المستوى ORCID يصنع.
الانتقال إلى الإصدار 2.0 من API - لماذا - ORCID، فضلا عن ORCID المجتمع - هل تحتاج هذه الترقية؟
أول ORCID API ، الذي تم إطلاقه في أكتوبر 2012 ، كان حتمًا يعتمد على العديد من الافتراضات التي أثبتت لاحقًا أنها خاطئة و / أو تتطلب تنقيحًا. لخدمة مجتمع البحث بشكل أفضل ، يتعين علينا فحص هذه الافتراضات باستمرار. إن استخدام التعليقات وطرح الأسئلة والنظر في الأدلة التي لم تكن متوفرة قبل إطلاقنا قد أعطانا رؤى جديدة حول ماهية ORCID API يجب أن لا يكون كذلك. كما سترى من إجابتي على السؤال التالي ، يمثل الإصدار 2.0 انفصالًا كبيرًا عن الافتراضات التي تم بناء 1.0 عليها ، بينما لا يزال عمليًا بدرجة كافية لتوفير الاستمرارية بين واجهتي برمجة التطبيقات.
ما هي الاختلافات الرئيسية بين 1.2 و 2.0 وكيف ستفيد الأعضاء؟
في تطوير الإصدار 2.0 ، أردنا معالجة العوائق التي واجهها الأعضاء بـ 1.2 وكذلك تقديم وظائف جديدة نعلم أن المجتمع يريدها.
بالإضافة إلى معالجة المشكلات المعروفة مثل قابلية التوسع في إدارة المنشورات شديدة التأليف ، والتحديات المتعلقة بالسلوك الضمني الذي تسبب في إرباك الأعضاء ، فقد أضفنا أيضًا وظائف جديدة لدعم التعرف على مراجعة الأقران ، وتحسين الإخطارات للمستخدمين ، والقدرة على دعم أي تقريبا المعرف الدائم.
لشرح سبب الحاجة إلى بعض هذه التغييرات ، سأحصل على القليل من التقنية. قبل أن نبدأ في ترميز سطر جديد واحد ، وضعنا قائمة بالأشياء التي أردنا تحسينها ، باستخدام "البيان" التالي:
- توقف عن التفكير في ORCID سجل كمستند متجانسة (مفردة كبيرة). مؤسسات متعددة الكتابة إلى ORCID السجل يعني التعرف على السجل متعدد المستأجرين. بالإضافة إلى ذلك ، غالبًا ما ينتج الباحثون مثل هذه الكميات الهائلة من الأبحاث التي لا تتناسب حتى ملخصاتها مع وثيقة متجانسة.
- نطاقات مبسطة. تعد دقة نطاقات الأذونات في 1.0 API أمرًا ساحقًا لجميع الأطراف المعنية ؛ تبسيطها سيجعل الحياة أسهل للمطورين والمستخدمين على حدٍ سواء.
- صريح مريح سلوك. تعتبر السلوكيات الضمنية سيئة للمنفذين لأنها تؤدي إلى سلوك غير متوقع يؤدي بدوره إلى إرباك المستخدمين النهائيين. باستخدام أسلوب RESTful ، تتجنب واجهة برمجة التطبيقات الجديدة الخاصة بنا هذه المشكلات.
- أقصر عناوين url معقولة. مثال جيد سيكون / Works / 1234 أفضل من /orcid-يعمل / 1234.
- استدعاءات لإرجاع الملخصات فقط. من أجل جعل استدعاء سجل أسرع ، يقوم API 2.0 فقط بإرجاع ملخصات للقوائم. إجراء مكالمة واحدة لكل جزء من المعلومات حول الباحث لا يصلح للمقالات شديدة التأليف ، حيث يوجد العشرات أو المئات أو حتى الآلاف من المؤلفين.
- الأسماء والتراكيب الشائعة للعناصر المشتركة. 2.0 يمكننا التأكد من أن العناصر المشتركة في XML / JSON لها نفس الأسماء.
- رموز الخطأ. نقوم الآن بتضمين رموز الخطأ في نص الاستجابة عندما لا يتم وصف الخطأ بالكامل بواسطة رمز HTTP قياسي.
وما هي الفوائد التي تعود على المستخدمين؟
في نهاية اليوم ، يجب أن تكون واجهة برمجة التطبيقات سلسة للمستخدمين. يتصاعد سلوك 1.0 غير متوقع ويؤثر على تجربة المستخدم بينما يحبط في نفس الوقت المطورين الذين ينفذون واجهة برمجة التطبيقات. على المستوى العملي ، تتيح واجهة برمجة التطبيقات الجديدة تبسيط كل قسم في ORCID سجل لتوفير تطبيق ثابت لإعدادات الرؤية والمصدر وتاريخ الإنشاء للعناصر في كل قسم.
هل سيؤثر ذلك على واجهة برمجة التطبيقات العامة أيضًا؟ كيف؟
نعم. التغييرات التي يتم إجراؤها على Member API و Public API تكون دائمًا ثابتة. على الرغم من أننا نقدر دعم الأعضاء ونعتمد عليه ، فإننا ملتزمون أيضًا برؤيتنا الأكبر "لعالم يتم فيه تحديد جميع المشاركين في البحث والمنح الدراسية والابتكار بشكل فريد وربطهم بمساهماتهم عبر التخصصات والحدود والوقت". نحن نرى واجهة برمجة التطبيقات العامة كوسيلة للمساعدة في تحقيق هذا الهدف.
برأيك ، ما هي التحديات الرئيسية في طرح الإصدار الجديد ، وماذا سيكون الدعم ORCID يتم تقديم؟
أصعب مشكلة هي تخصيص الموارد للقيام بالعمل ترقية. بالنسبة لبعض المنظمات ، قد يستغرق الأمر أقل من يومين وقد يتطلب البعض الآخر شهرًا كاملاً. بغض النظر عن الإطار الزمني ، لا تخف من التواصل وطلب المساعدة ، حتى لو كان القليل من التفاصيل التي توقف تقدمك. وثائق كاملة متاح الآن على الأعضاء.orcid.org و ORCID يمكن للمنظمات الأعضاء أيضًا تواصل معنا. الإرسال إلى منتدى مستخدمي API يمكن أن يكون مفيدًا ، حيث يتم جلب التعليقات من جميع أنحاء ORCID تواصل اجتماعي. أنا أيضًا من أشد المؤمنين بكوني متاحًا بشكل مباشر ، لذا لا تتردد في ذلك راسلني مباشرة.
من يستخدم API 2.0 حاليًا وما نوع التعليقات التي قدموها؟
لقد بذلنا الكثير من الجهد لإتاحة المرشحين للإصدار من أجل الحصول على التعليقات. تعد CrossRef و Datacite و CERN و PTCRIS مجرد أمثلة قليلة من ORCID الأعضاء الذين قاموا بتطبيق مرشح الإصدار وقدموا تعليقات. بالإضافة إلى ذلك ، قامت العديد من المنظمات بتطبيق وظيفة مراجعة الأقران باستخدام الإصدار 2.0 ، بما في ذلك المتبنين الأوائل ، والاتحاد الجيوفيزيائي الأمريكي ، و F1000 ، و Publons. تضمنت التعليقات الاقتراحات "الفنية" المعتادة مثل الأسماء المستخدمة في المخطط أو تسمية نقطة النهاية أو المناقشات حول الكفاءة. يمكن أن يكون لهذا النوع من التفاصيل آثار كبيرة على الأعضاء. ومع ذلك ، فإن منفذي الإصدار المرشحين يقدمون أيضًا تعليقات من منظور الباحث ، والتي نجدها لا تقدر بثمن.
كم من الوقت سوف ORCID الاستمرار في دعم واجهة برمجة التطبيقات القديمة؟
نحن نهدف إلى غروب الشمس 1.2 في أواخر عام 2017. بغض النظر عن تاريخ الغروب ، إذا كنت توافق على ذلك ORCIDمهمة ويهتم بالباحثين الذين يتفاعلون معهم ORCID سترغب في الانتقال إلى الإصدار 2.0 الآن.
أي شيء آخر يجب أن نعرفه عن هذا التغيير؟
نأمل أن يثبت الإصدار 2.0 على أنه دائم ويمكننا التركيز على أجزاء أخرى من ORCID كومة التكنولوجيا لفترة جيدة!
للحصول على ملخص سهل وممتع لميزات API 2.0 ، راجع هذا الشريحة سطح السفينة!