ORCID 一度に2つの主要なAPIバージョンをサポートすることを目的としています。新しいメジャーAPIバージョンがリリースされると、 ORCID リリース日から少なくとも12年間のサポートを保証します。さらに、最も古いメジャーバージョンを廃止する前にXNUMXか月前に通知し、通知期間中に引き続き使用しているメンバーに定期的にリマインダーメールを送信します。メタデータスキーマに重大な変更を加えるたびに新しいメジャーバージョンが必要になり、メジャーバージョン番号の増分で示されます。 ORCID 2〜4年ごとに新しいメジャーAPIバージョンをリリースします。

例外的な状況では、 ORCID 新しいメジャーAPIバージョンがリリースされたときに12か月の廃止期間を延長することを検討する場合がありますが、これには ORCID メンテナンス作業に追加のリソースを投資し、その結果、新しい開発やサポートなどの他のアクティビティに影響を与えます。 ORCID 発生した追加コストを相殺するために、廃止されたAPIバージョンを廃止日以降も継続して使用する場合は追加料金を請求する権利を留保します。

ORCID には、APIの提供を進化させ、メジャーリリース間のコミュニティのニーズに対応できるようにする増分API非推奨ポリシーがあります。この意味は ORCID 現在のAPIバージョンの統制語彙とメタデータフィールドに重大な変更を加える可能性があります。

最新のAPIバージョンのユーザーは、これらの変更を自由に無視できますが、変更が加えられる可能性があることに注意してください。
以前のAPIバージョンのユーザーは、自分のバージョンでモデル化できないデータを受け取りません。

これを書いている時点での例は、v3.0APIへのCREDITコントリビューターロールタクソノミーの導入です。ライブになると、v2.x統合は、ますます多くの研究者と統合がCREDITを採用するにつれて、貢献者の役割の可視性を徐々に失います。 V2.xユーザーは壊れることはありませんが、時間が経つにつれて、よりリッチなメタデータを受け取るようになります。

新しいメジャーAPIバージョンを開発する場合、 ORCID 「リリース候補」バージョンを作成します。これらは、APIのフルバージョンがリリースされた後、タイムリーにアップグレードできるインテグレーターを対象としています。リリース候補の予想寿命は、それが開発されたメジャーバージョンのリリースから最大12か月です。

インテグレーターは以下に従うことをお勧めしますロバストネス原則（別名ポステルの法則）を利用する場合 ORCID APIです。

経歴

ORCID 謙虚な始まりからAPIをゆっくりと進化させてきました。

API v1.x（レジストリと一緒に〜2012を起動）は、研究者とその活動に関するすべてのメタデータを単一のAPI応答で返そうとしました。インテグレーターは、新しいアイテムを追加したり、既存のアイテムを更新したりするために、このメタデータを変更して全体を送り返す必要がありました。これは妥当な最初の試みでしたが、拡張性がなく、追加や更新を行うのは骨の折れる作業でした。（2018年XNUMX月に引退）

API 2.x（2017年XNUMX月にリリース）は、APIをセクションに分割しました。仕事、所属、資金調達、伝記など。それは大きな前進であり、私たち自身と私たちのクライアントの両方が大きな記録をはるかに簡単に管理することを可能にしました。ただし、検証と統制語彙の多くはスキーマにハードコーディングされているため、変更への対応が困難です。

API 3.x（2019年XNUMX月リリース）は、研究リソースなどの新しいセクションをレコードに追加し、スキーマ構造を簡素化し、提供しました ORCID 追加の柔軟性を備えています。検証の多くをスキーマからサーバーに移動しました。これにより、APIのバージョンをさらにリリースすることなく、問題を修正し、新しい識別子タイプを追加できるようになりました。

新しい主要なAPIのリリースは大きな仕事です。それを作成するには何年もの開発者の努力が必要であり、メンバーは統合をアップグレードするためにさらに何年も必要です。このため、変更を制限しようとしています。ただし、コミュニティに最適なサービスを提供するために、いくつかの変更を加えたいと考えています。

私たちの仕事は、APIの新しいバージョンをリリースするためのクリティカルマスがあるときに解決すること、または既存の統合を壊すことなく既存のAPIを更新する方法を解決することです。