在這次採訪中,羅伯·彼得斯, ORCID技術總監介紹 ORCID的新 API – 14 年 2017 月 XNUMX 日推出
在我們開始談論新的 API 之前,你能告訴我們一些關於 ORCID的技術團隊和您作為總監的角色?
乍一看, ORCID 團隊看起來很像任何其他技術團隊。 我們有五個開發人員,一個服務器管理員,一個質量保證分析師,當然還有一個經理(我)。 然而,有趣的是我們不同的地理、文化和工作背景。 我們三個人在美國,三個人在哥斯達黎加,兩個人在英國,所以在地理上我們有很多觀點。 此外,我們中的一些人來自傳統軟件諮詢,其他人來自出版業、“矽谷”初創公司和圖書館學。
我作為技術總監的個人角色是管理日常軟件開發。 這歸結為幫助我的團隊相互溝通以及與組織的其他成員溝通,以及管理團隊承擔哪些任務(以及哪些任務被推遲)。 我也有機會對更高級別的戰略決策有很多投入 ORCID 製造。
轉向 API 2.0 版——我們為什麼要—— ORCID,以及作為 ORCID 社區 – 需要升級嗎?
第一 ORCID API 於 2012 年 XNUMX 月推出,不可避免地基於許多後來被證明是錯誤的和/或需要改進的假設。 為了更好地為研究界服務,我們必須不斷檢查這些假設。 使用反饋、提出問題並查看我們發布之前無法獲得的證據,讓我們對 ORCID API 應該也不應該是。 正如您將在我對下一個問題的回答中看到的那樣,2.0 版代表了對構建 1.0 的假設的重大突破,同時仍然足夠務實以提供兩個 API 之間的連續性。
1.2 和 2.0 之間的主要區別是什麼?它們將如何使會員受益?
在開發 2.0 時,我們既要解決成員在 1.2 中遇到的障礙,又要引入我們知道社區需要的新功能。
因此,除了解決已知問題,例如管理超級作者出版物的可擴展性,以及導致成員混淆的隱性行為挑戰,我們還添加了新功能以支持同行評審識別、改進用戶通知以及支持幾乎任何 持久標識符。
為了解釋為什麼需要這些更改中的一些,我將獲得一些技術性的知識。 在開始編寫新的一行代碼之前,我們列出了我們希望改進的地方,並附有以下“宣言”:
- 停止思考 ORCID 記錄為整體(大單)文檔。 多個機構寫信給一個 ORCID 記錄意味著識別記錄是 多租戶. 此外,研究人員經常進行大量的研究,即使是對它的總結也不適合放在一個單一的文檔中。
- 簡化的範圍. 1.0 API 中權限範圍的粒度對於所有相關方來說都是壓倒性的; 簡化它們將使開發人員和用戶的生活更輕鬆。
- 明確的 REST風格 行為. 隱性行為對實施者不利,因為它們會導致意外行為,進而使最終用戶感到困惑。 通過使用 RESTful 行為,我們的新 API 避免了這些問題。
- 最短的合理網址. 一個很好的例子是 /works/1234 比 /orcid-作品/1234。
- 調用列表僅返回摘要. 為了更快地調用記錄,API 2.0 只返回列表的摘要。 對研究人員的每條信息都進行一次調用並不適用於超級作者的文章,因為那裡有數十、數百甚至數千名作者。
- 通用元素的通用名稱和結構. 2.0 使我們能夠確保 XML/JSON 中的公共元素具有相同的名稱。
- 錯誤代碼. 當標準 HTTP 代碼未完全描述錯誤時,我們現在在響應正文中包含錯誤代碼。
對用戶有什麼好處?
歸根結底,API 應該對用戶是無縫的。 意外的 1.0 行為冒泡並影響用戶體驗,同時讓正在實施 API 的開發人員感到沮喪。 在實用層面上,新的 API 可以簡化每個部分 ORCID 記錄以一致地為每個部分中的項目提供可見性設置、來源和創建日期的應用。
這也會影響公共 API 嗎? 如何?
是的。 對成員 API 和公共 API 的更改始終保持同步。 儘管我們感謝並依賴成員的支持,但我們也致力於實現我們更大的願景,“在這個世界裡,所有參與研究、學術和創新的人都被獨特地識別出來,並與他們跨越學科、國界和時間的貢獻相關聯。” 我們將公共 API 視為幫助實現該目標的一種手段。
您認為推出新版本的主要挑戰是什麼,以及將提供哪些支持? ORCID 提供?
最困難的問題是留出資源來完成工作 升級. 對於某些組織,它可能只需幾天,而其他組織可能需要整整一個月。 無論時間安排如何,都不要害怕伸出手尋求幫助,即使是一些阻礙您進步的細節。 完整文件 現在可以在會員上使用。orcid.org和 ORCID 會員組織也可以 聯繫我們 (contact us). 發佈到 API 用戶論壇 可能很有用,帶來來自各地的評論 ORCID 社區。 我也堅信直接可用,所以覺得 直接給我發電子郵件.
目前誰在使用 API 2.0,他們提供了什麼樣的反饋?
為了獲得反饋,我們付出了很多努力來提供候選版本。 CrossRef、Datacite、CERN 和 PTCRIS 只是其中的一小部分 ORCID 已實施候選版本並提供反饋的成員。 此外,一些組織已經使用 2.0 實現了同行評審功能,包括早期採用者、美國地球物理聯盟、F1000 和 Publons。 反饋包括通常的“技術人員”建議,例如模式中使用的名稱、端點命名或關於效率的辯論。 這些細節可能對會員產生重大影響。 然而,候選版本的實施者也從研究人員的角度提供反饋,我們認為這是非常寶貴的。
要多久 ORCID 繼續支持舊 API?
我們的目標是在 1.2 年末推出 2017。無論日落日期如何,如果您同意 ORCID的使命 並關心研究人員與之互動 ORCID 你現在想要遷移到 2.0。
關於這個變化,我們還應該知道什麼?
我們希望 2.0 被證明是持久的,我們可以專注於其他部分 ORCID 技術棧好一陣子了!
有關 API 2.0 功能的有趣且方便的摘要,請參閱此 滑台!