W tym wywiadzie Rob Peters, ORCID's Director of Technology, przedstawia ORCIDnowy interfejs API — uruchomiony 14 lutego 2017 r
Zanim zaczniemy mówić o nowym interfejsie API, czy możesz nam coś o nim powiedzieć ORCIDZespołu Technicznego a Twoja rola jako Dyrektora?
Na pierwszy rzut oka ORCID zespół wygląda jak każdy inny zespół techniczny. Mamy pięciu programistów, administratora serwera, analityka ds. zapewnienia jakości i oczywiście menedżera (ja). Jednak tam, gdzie robi się interesująco, jest nasze różne pochodzenie geograficzne, kulturowe i zawodowe. Trzech z nas mieszka w USA, trzech w Kostaryce, a dwóch w Wielkiej Brytanii, więc geograficznie mamy dużo perspektywy. Ponadto niektórzy z nas wywodzą się z tradycyjnego konsultingu w zakresie oprogramowania, inni z branży wydawniczej, startupów z „Doliny Krzemowej” i bibliotekoznawstwa.
Moją osobistą rolą jako dyrektora ds. technologii jest zarządzanie codziennym rozwojem oprogramowania. Sprowadza się to do pomocy mojemu zespołowi w komunikacji między sobą i resztą organizacji, a także do zarządzania zadaniami, które zespół podejmuje (a które odkładają). Mam również możliwość wniesienia dużego wkładu w decyzje strategiczne wyższego szczebla ORCID robi.
Przejście na API w wersji 2.0 – dlaczego – ORCID, Jak również ORCID społeczność – potrzebujesz tej aktualizacji?
Pierwszy ORCID API, które zostało uruchomione w październiku 2012 roku, nieuchronnie opierało się na wielu założeniach, które później okazały się błędne i/lub wymagały dopracowania. Aby lepiej służyć społeczności badawczej, musimy stale badać te założenia. Korzystanie z informacji zwrotnych, zadawanie pytań i przeglądanie dowodów, które nie były dostępne przed uruchomieniem, dało nam nowy wgląd w to, czym jest ORCID API powinno i nie powinno być. Jak zobaczysz z mojej odpowiedzi na następne pytanie, wersja 2.0 stanowi duże zerwanie z założeniami, na których zbudowano wersję 1.0, a jednocześnie jest wystarczająco pragmatyczna, aby zapewnić ciągłość między dwoma interfejsami API.
Jakie są główne różnice między 1.2 a 2.0 i jakie korzyści przyniosą one członkom?
Opracowując wersję 2.0, chcieliśmy zarówno zająć się przeszkodami, na które napotykali członkowie w wersji 1.2, jak i wprowadzić nowe funkcje, których oczekuje społeczność.
Tak więc oprócz rozwiązywania znanych problemów, takich jak skalowalność w zarządzaniu publikacjami hiperautorskimi i wyzwaniami związanymi z niejawnymi zachowaniami, które powodowały dezorientację członków, dodaliśmy także nowe funkcje wspierające rozpoznawanie recenzentów, ulepszone powiadomienia dla użytkowników oraz możliwość wspierać prawie każdego trwały identyfikator.
Aby wyjaśnić, dlaczego niektóre z tych zmian były potrzebne, przejdę do kwestii technicznych. Zanim przystąpiliśmy do kodowania pojedynczej nowej linii, sporządziliśmy listę rzeczy, które chcielibyśmy poprawić, z następującym „manifestem”:
- Przestań myśleć o ORCID zapis jako monolityczny (duży pojedynczy) dokument. Wiele instytucji piszących do an ORCID rekord oznacza rozpoznanie rekordu wielu najemców. Ponadto badacze często tworzą tak ogromną liczbę badań, że nawet ich streszczenia nie zmieszczą się w monolitycznym dokumencie.
- Uproszczone zakresy. Szczegółowość zakresów uprawnień w interfejsie API 1.0 jest przytłaczająca dla wszystkich zaangażowanych stron; uproszczenie ich ułatwi życie zarówno programistom, jak i użytkownikom.
- Wyraźny Spokojny zachowanie. Niejawne zachowania są złe dla implementatorów, ponieważ prowadzą do nieoczekiwanego zachowania, które z kolei dezorientuje użytkowników końcowych. Dzięki zastosowaniu zachowania RESTful nasz nowy interfejs API pozwala uniknąć tych problemów.
- Najkrótsze rozsądne adresy URL. Dobrym przykładem może być /works/1234 jest lepszy niż /orcid-działa/1234.
- Wezwania do wyświetlenia zwracają tylko podsumowania. Aby przyspieszyć wywoływanie rekordu, API 2.0 zwraca tylko podsumowania list. Wykonywanie jednego wezwania dla każdej informacji o badaczu nie działa w przypadku hiperautorskich artykułów, w których są dziesiątki, setki, a nawet tysiące autorów.
- Wspólne nazwy i struktury wspólnych elementów. 2.0 pozwala nam upewnić się, że wspólne elementy w XML/JSON mają takie same nazwy.
- kody błędów. Teraz dołączamy kody błędów w treści odpowiedzi, gdy błąd nie jest w pełni opisany przez standardowy kod HTTP.
A jakie są korzyści dla użytkowników?
Pod koniec dnia interfejs API powinien być bezproblemowy dla użytkowników. Nieoczekiwane zachowanie wersji 1.0 narasta i wpływa na wrażenia użytkownika, jednocześnie frustrując programistów wdrażających interfejs API. Na poziomie praktycznym nowy interfejs API umożliwia usprawnienie każdej sekcji w ORCID rekord, aby konsekwentnie zapewniać zastosowanie ustawień widoczności, źródła i daty utworzenia elementów w każdej sekcji.
Czy wpłynie to również na publiczny interfejs API? Jak?
Tak. Zmiany w Member API i Public API są zawsze na bieżąco. Chociaż doceniamy wsparcie członków i polegamy na nim, jesteśmy również zaangażowani w naszą szerszą wizję „świata, w którym wszyscy, którzy uczestniczą w badaniach, stypendium i innowacjach, są jednoznacznie identyfikowani i powiązani ze swoim wkładem ponad dyscyplinami, granicami i czasem”. Postrzegamy Public API jako sposób na osiągnięcie tego celu.
Jak myślisz, jakie będą główne wyzwania związane z wdrażaniem nowej wersji i jakie będzie wsparcie ORCID dostarczać?
Najtrudniejszym problemem jest odłożenie zasobów na wykonanie pracy uaktualnienie. W przypadku niektórych organizacji może to być zaledwie kilka dni, a inne mogą wymagać pełnego miesiąca. Niezależnie od ram czasowych, nie bój się wyciągać ręki i prosić o pomoc, nawet w przypadku drobnego szczegółu, który powstrzymuje Twój postęp. Pełna dokumentacja jest już dostępny dla członków.orcid.org i ORCID organizacje członkowskie również mogą skontaktuj się z nami. Wysyłanie do Forum użytkowników API mogą być przydatne, przynosząc komentarze z całego świata ORCID wspólnota. Mocno wierzę również w bezpośrednią dostępność, więc nie krępuj się napisz do mnie bezpośrednio.
Kto obecnie korzysta z API 2.0 i jakiego rodzaju informacje zwrotne przekazał?
Włożyliśmy wiele wysiłku w udostępnienie kandydatów do wydania w celu uzyskania opinii. CrossRef, Datacite, CERN i PTCRIS to tylko niektóre z nich ORCID członków, którzy wdrożyli wersję Release Candidate i przekazali opinie. Ponadto kilka organizacji wdrożyło funkcję wzajemnej oceny przy użyciu wersji 2.0, w tym pierwsi użytkownicy, American Geophysical Union, F1000 i Publons. Informacje zwrotne zawierały typowe „techniczne” sugestie, takie jak nazwy używane w schematach, nazewnictwo punktów końcowych lub debaty na temat wydajności. Tego rodzaju szczegóły mogą mieć duże implikacje dla członków. Jednak osoby wdrażające Release Candidate dostarczają również informacji zwrotnych z perspektywy badacza, co uważamy za nieocenione.
Jak długo będzie ORCID nadal obsługiwać stary interfejs API?
Naszym celem jest wygaśnięcie 1.2 pod koniec 2017 r. Niezależnie od daty wygaśnięcia, jeśli zgadzasz się z ORCIDmisja i dbają o interakcje naukowców ORCID teraz będziesz chciał przejść na wersję 2.0.
Czy coś jeszcze powinniśmy wiedzieć o tej zmianie?
Mamy nadzieję, że wersja 2.0 okaże się trwała i będziemy mogli skupić się na innych częściach ORCID stos technologii na dobrą chwilę!
Zabawne i przydatne podsumowanie funkcji interfejsu API 2.0 można znaleźć tutaj zjeżdżalnia!