V tomto rozhovoru Rob Peters, ORCIDPředstavuje technologický ředitel ORCIDNové API - spuštěno 14. února 2017
Než začneme mluvit o novém API, můžete nám něco říct ORCIDTechnický tým a vaše role ředitele?
Na první pohled ORCID tým vypadá podobně jako jakýkoli jiný technický tým. Máme pět vývojářů, správce serveru, analytika pro zajištění kvality a samozřejmě manažera (mě). Kde to však bude zajímavé, jsou naše různá geografická, kulturní a pracovní prostředí. Tři z nás se sídlem v USA, tři se sídlem v Kostarice a dva se sídlem ve Velké Británii, takže z geografického hlediska máme velkou perspektivu. Někteří z nás navíc pocházejí z tradičního softwarového poradenství, jiní pocházejí z vydavatelského průmyslu, startupů „Silicon Valley“ a knihovnických věd.
Moje osobní role jako technologického ředitele je řízení každodenního vývoje softwaru. To se scvrkává na to, že pomáhám mému týmu komunikovat mezi sebou navzájem a zbytkem organizace, stejně jako řídit, které úkoly tým přebírá (a které se odradí). Dostávám také příležitost hodně se podílet na strategických rozhodnutích na vyšší úrovni ORCID dělá.
Přechod na API verze 2.0 - proč - ORCID, Jakož i ORCID komunita - potřebujete tento upgrade?
První ORCID API, které bylo spuštěno v říjnu 2012, bylo nevyhnutelně založeno na mnoha předpokladech, které se později ukázaly jako špatné a / nebo vyžadovaly rafinaci. Abychom lépe sloužili výzkumné komunitě, musíme tyto předpoklady neustále zkoumat. Používání zpětné vazby, kladení otázek a zkoumání důkazů, které nebyly k dispozici před spuštěním, nám poskytlo nové poznatky o tom, co ORCID API by mělo a nemělo být. Jak uvidíte z mé odpovědi na další otázku, verze 2.0 představuje zásadní zlom od předpokladů, na kterých byla verze 1.0 postavena, přičemž je stále dostatečně pragmatická, aby poskytovala kontinuitu mezi těmito dvěma API.
Jaké jsou hlavní rozdíly mezi 1.2 a 2.0 a jak budou mít prospěch pro členy?
Při vývoji 2.0 jsme chtěli řešit překážky, které členové narážejí na 1.2, a také zavést nové funkce, o kterých víme, že je komunita chce.
Kromě řešení známých problémů, jako je škálovatelnost při správě publikací s hyperautorem, a problémy s implicitním chováním, které u členů způsobovalo zmatek, jsme také přidali nové funkce pro podporu rozpoznávání vzájemných recenzí, vylepšená oznámení pro uživatele a schopnost podporovat téměř všechny trvalý identifikátor.
Abych vysvětlil, proč byly některé z těchto změn potřeba, půjdu trochu technicky. Než jsme se pustili do kódování jednoho nového řádku, vytvořili jsme seznam věcí, které jsme chtěli vidět vylepšené, pomocí následujícího „manifestu“:
- Přestaňte myslet na ORCID záznam jako monolitický (velký jednotlivý) dokument. Více institucí, které píšou do ORCID záznam znamená rozpoznání záznamu je více nájemců. Vědci navíc často vytvářejí tak obrovské množství výzkumu, že ani jeho shrnutí se nevejdou do monolitického dokumentu.
- Zjednodušené obory. Granularita rozsahů oprávnění v rozhraní API 1.0 je pro všechny zúčastněné strany ohromující; jejich zjednodušení usnadní vývojářům i uživatelům život.
- Explicitní Klidný chování. Implicitní chování je pro implementátory špatné, protože vede k neočekávanému chování, které naopak matoucí koncové uživatele. Díky našemu chování RESTful se naše nové API těmto problémům vyhne.
- Nejkratší rozumné adresy URL. Dobrým příkladem by bylo / funguje / 1234 je lepší než /orcid-práce / 1234.
- Výzvy k zobrazení pouze návratových souhrnů. Aby bylo volání záznamu rychlejší, API 2.0 vrací pouze souhrny pro seznamy. Udělat jedno volání za každou informaci o výzkumníkovi nefunguje u článků s autorským hypertextem, kde jsou desítky, stovky nebo dokonce tisíce autorů.
- Společné názvy a struktury pro společné prvky. 2.0 nám umožňuje zajistit, aby společné prvky v XML / JSON měly stejné názvy.
- Chybové kódy. Pokud chyba není plně popsána standardním kódem HTTP, nyní do těla odpovědi zahrneme chybové kódy.
A jaké jsou výhody pro uživatele?
Na konci dne by rozhraní API mělo být pro uživatele bezproblémové. Neočekávané chování 1.0 bubliny a ovlivňuje uživatelské zkušenosti a zároveň frustruje vývojáře, kteří implementují API. Na praktické úrovni nové API umožňuje zefektivnění každé sekce v ORCID záznam, který důsledně poskytuje aplikaci nastavení viditelnosti, zdroje a data vytvoření pro položky v každé sekci.
Ovlivní to také veřejné API? Jak?
Ano. Změny rozhraní API člena a veřejného rozhraní API jsou vždy v lockstepu. I když si vážíme a spoléháme na podporu členů, zavázali jsme se také k naší větší vizi „světa, kde všichni, kteří se účastní výzkumu, stipendia a inovací, jsou jedinečně identifikováni a spojeni s jejich příspěvky napříč obory, hranicemi a časem.“ Veřejné API považujeme za prostředek, jak pomoci dosáhnout tohoto cíle.
Co si myslíte, že budou hlavní výzvy při zavádění nové verze a jaká bude podpora ORCID poskytovat?
Nejtěžším problémem je odložení zdrojů, aby bylo možné tuto práci vykonat upgradovat. Pro některé organizace to může být jen pár dní a jiné mohou vyžadovat celý měsíc. Bez ohledu na časový rámec se nebojte oslovit a požádat o pomoc, a to i pro malé detaily, které brzdí váš pokrok. Kompletní dokumentace je nyní k dispozici pro členy.orcid.org a ORCID členské organizace mohou také kontaktujte nás. Vysílání do Fórum uživatelů API může být užitečné, přináší připomínky z celého internetu ORCID společenství. Také pevně věřím v to, že jsem přímo k dispozici, takže neváhejte napište mi přímo.
Kdo aktuálně používá API 2.0 a jaký druh zpětné vazby poskytl?
Vynaložili jsme velké úsilí na zpřístupnění kandidátů na vydání, abychom získali zpětnou vazbu. CrossRef, Datacite, CERN a PTCRIS jsou jen některé z nich ORCID členové, kteří implementovali kandidáta na vydání a poskytli zpětnou vazbu. Několik organizací navíc implementovalo funkce peer review pomocí 2.0, včetně prvních uživatelů, American Geophysical Union, F1000 a Publons. Zpětná vazba zahrnovala obvyklá „technická“ doporučení, jako jsou názvy používané ve schématu, pojmenování koncových bodů nebo debaty o efektivitě. Tyto podrobnosti mohou mít pro členy velké důsledky. Implementátoři kandidátů na vydání však také poskytují zpětnou vazbu z pohledu výzkumného pracovníka, což považujeme za neocenitelné.
Jak dlouho bude ORCID nadále podporovat staré API?
Naším cílem je západ slunce 1.2 koncem roku 2017. Bez ohledu na datum západu slunce, pokud s tím souhlasíte ORCIDmise a péče o výzkumné pracovníky ORCID nyní budete chtít přejít na verzi 2.0.
Ještě něco, co bychom měli o této změně vědět?
Doufáme, že 2.0 bude odolný a že se můžeme zaměřit na jiné části ORCID technologický zásobník na dobrou chvíli!
Zábavné a praktické shrnutí funkcí rozhraní API 2.0 najdete v tomto článku skluzavka!