このインタビューでは、ロブ・ピーターズ、 ORCIDのテクノロジーディレクターが紹介します ORCIDの新しいAPI– 14年2017月XNUMX日にリリース
新しいAPIについて説明する前に、少し教えていただけますか ORCIDの技術チームとディレクターとしてのあなたの役割は?
一見すると、 ORCID チームは他の技術チームとよく似ています。 XNUMX人の開発者、サーバー管理者、品質保証アナリスト、そしてもちろんマネージャー(私)がいます。 ただし、興味深いのは、地理的、文化的、および仕事上のさまざまな背景です。 私たちのうちXNUMX人は米国を拠点とし、XNUMX人はコスタリカを拠点とし、XNUMX人は英国を拠点としているため、地理的に多くの視点を得ることができます。 さらに、私たちの中には、従来のソフトウェアコンサルティングの出身者もいれば、出版業界、「シリコンバレー」の新興企業、図書館学の出身者もいます。
テクノロジーディレクターとしての私の個人的な役割は、日々のソフトウェア開発を管理することです。 つまり、私のチームがお互いに、そして組織の他のメンバーとコミュニケーションをとるのを助け、チームがどのタスクを引き受けるか(そしてどのタスクを延期するか)を管理することになります。 また、より高いレベルの戦略的決定について多くの意見を得る機会もあります。 ORCID 作る。
APIバージョン2.0への移行–なぜ私たち– ORCID、並びに ORCID コミュニティ–このアップグレードが必要ですか?
最初の ORCID 2012年XNUMX月にリリースされたAPIは、必然的に、後で間違っていることが判明したり、改良が必要になったりする多くの仮定に基づいていました。 研究コミュニティにより良いサービスを提供するために、私たちはこれらの仮定を継続的に検討する必要があります。 フィードバックを使用し、質問をし、立ち上げ前には入手できなかった証拠を調べることで、 ORCID APIはそうあるべきであり、そうすべきではありません。 次の質問への私の回答からわかるように、バージョン2.0は、1.0が構築されたという仮定からの大きな脱却を表していますが、XNUMXつのAPI間の継続性を提供するのに十分実用的です。
1.2と2.0の主な違いは何ですか?また、それらはメンバーにどのように役立ちますか?
2.0の開発では、メンバーが1.2で直面している障害に対処すると同時に、コミュニティが望んでいることがわかっている新しい機能を導入したいと考えました。
そのため、ハイパーオーサリングされた出版物の管理におけるスケーラビリティや、メンバーの混乱を引き起こしていた暗黙の動作に関する課題などの既知の問題に取り組むだけでなく、ピアレビューの認識をサポートする新しい機能、ユーザーへの通知の改善、およびほぼすべてをサポート 永続的な識別子。
これらの変更のいくつかが必要な理由を説明するために、少し技術的に説明します。 XNUMXつの新しい行のコーディングに着手する前に、次の「マニフェスト」を使用して、改善してほしいもののリストを作成しました。
- 考えるのをやめなさい ORCID モノリシック(ラージシングル)ドキュメントとして記録します。 複数の機関が ORCID レコードとは、レコードを認識することを意味します マルチテナント。 さらに、研究者はしばしば、その要約でさえモノリシック文書に収まらないほど膨大な量の研究を生み出します。
- 簡略化されたスコープ。 1.0 APIのパーミッションスコープの粒度は、関係するすべての関係者にとって圧倒的です。 それらを単純化すると、開発者とユーザーの両方の生活が楽になります。
- 明白な RESTful 行動。 暗黙の動作は、予期しない動作につながり、エンドユーザーを混乱させるため、実装者にとっては悪いことです。 RESTful動作を使用することで、新しいAPIはこれらの問題を回避します。
- 最短の妥当なURL。 良い例は/ works / 1234が/よりも優れていることですorcid-作品/ 1234。
- リストへの呼び出しは要約のみを返します。 レコードの呼び出しを高速化するために、API2.0はリストの要約のみを返します。 研究者に関するすべての情報に対してXNUMX回の呼び出しを行うことは、数十、数百、さらには数千の著者がいるハイパーオーサリングされた記事では機能しません。
- 一般的な要素の一般的な名前と構造。 2.0を使用すると、XML / JSONの共通要素が同じ名前であることを確認できます。
- エラーコード。 エラーが標準のHTTPコードで完全に記述されていない場合に、応答本文にエラーコードを含めるようになりました。
そして、ユーザーにとってのメリットは何ですか?
結局のところ、APIはユーザーにとってシームレスである必要があります。 予期しない1.0の動作が発生し、ユーザーエクスペリエンスに影響を与えると同時に、APIを実装している開発者を苛立たせます。 実用的なレベルでは、新しいAPIにより、 ORCID 各セクションのアイテムの可視性設定、ソース、および作成日のアプリケーションを一貫して提供するために記録します。
これはパブリックAPIにも影響しますか? どうやって?
はい。 メンバーAPIとパブリックAPIへの変更は常にロックステップにあります。 私たちはメンバーのサポートに感謝し、信頼していますが、「研究、奨学金、イノベーションに参加するすべての人が独自に識別され、分野、国境、時間を超えて貢献する世界」というより大きなビジョンにも取り組んでいます。 パブリックAPIは、その目標の達成を支援する手段と見なしています。
新しいバージョンを展開する際の主な課題は何だと思いますか。また、どのようなサポートがありますか。 ORCID 提供していますか?
最も難しい問題は、作業を行うためのリソースを確保することです アップグレード。 組織によっては、数日かかる場合もあれば、XNUMXか月かかる場合もあります。 時間枠に関係なく、あなたの進歩を妨げている少しの詳細であっても、手を差し伸べて助けを求めることを恐れないでください。 完全なドキュメント メンバーが利用できるようになりました。orcid.orgおよび ORCID メンバー組織はまたすることができます Rescale Support。 への投稿 APIユーザーフォーラム 全体からコメントを持ち込むと便利です ORCID コミュニティ。 私も直接利用できることを固く信じているので、 直接メールしてください.
現在API2.0を使用しているのは誰ですか?また、どのようなフィードバックを提供していますか?
フィードバックを得るために、リリース候補を利用できるようにすることに多大な努力を払っています。 CrossRef、Datacite、CERN、およびPTCRISは、 ORCID リリース候補を実装し、フィードバックを提供したメンバー。 さらに、アーリーアダプター、アメリカ地球物理学連合、F2.0、Publonsなど、いくつかの組織が1000を使用してピアレビュー機能を実装しています。 フィードバックには、スキーマで使用される名前、エンドポイントの命名、効率に関する議論など、通常の「技術者」の提案が含まれています。 このような詳細は、メンバーに大きな影響を与える可能性があります。 ただし、リリース候補の実装者は、研究者の観点からフィードバックも提供します。これは非常に貴重です。
どのくらいの期間 ORCID 古いAPIを引き続きサポートしますか?
1.2年後半に2017の日没を目指しています。日没の日付に関係なく、同意する場合は ORCIDの使命 研究者との交流を気にする ORCID 今すぐ2.0に移行する必要があります。
この変更について他に知っておくべきことはありますか?
2.0が耐久性があり、他の部分に集中できることを願っています。 ORCID しばらくの間、テクノロジースタック!
API 2.0機能の楽しくて便利な要約については、こちらをご覧ください スライドデッキ!