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 的方法。