ORCID 旨在一次支持 2 個主要的 API 版本。 當新的主要 API 版本發佈時, ORCID 保證從發布之日起至少三年的支持。 此外,我們會在停用最舊的主要版本前提前 12 個月通知,並定期向在通知期內仍在使用它的會員發送提醒電子郵件。 每當我們對元數據模式進行重大更改時,都需要新的主要版本,並由主要版本號的增量表示。 ORCID 每 2-4 年發布一個新的主要 API 版本。
在特殊情況下, ORCID 可以考慮在新的主要 API 版本發佈時延長 12 個月的停用期,但這需要 ORCID 在維護工作中投入更多資源,從而對其他活動(例如新開發和支持)產生相應影響。 ORCID 保留對在停用日期之後繼續使用停用的 API 版本收取額外費用的權利,以幫助抵消產生的額外費用。
ORCID 有一個漸進式 API 棄用政策,允許我們改進 API 產品並在主要版本之間響應社區需求。 這意味著 ORCID 可以對當前 API 版本的受控詞彙表和元數據字段進行不間斷更改。
- 最新 API 版本的用戶可以隨意忽略這些更改,但應注意可能會發生這些更改
- 先前 API 版本的用戶將不會收到無法在其版本中建模的數據
撰寫本文時的一個示例是將 CREDIT 貢獻者角色分類法引入 v3.0 API。 一旦上線,隨著越來越多的研究人員和集成採用 CREDIT,v2.x 集成將慢慢失去貢獻者角色的可見性。 V2.x 用戶不會中斷,但隨著時間的推移,他們收到的元數據會越來越少。
在開發新的主要 API 版本時,對於 ORCID 生成“發布候選”版本。 這些針對的是能夠在 API 的完整版本發布後及時升級的集成商。 候選版本的預期生命週期是從其開發的主要版本發布起最多 12 個月。
我們建議集成商遵循 穩健性原則 (又名 Postel 定律)在使用 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 的方法。