Stable currents. Nick Veenstra. Developing against the Pure API

Transcription

1 Stable currents Nick Veenstra Developing against the Pure API

2 From public libraries into Library Information Systems Development (at INFOR and TU/e) Research Information Specialist at Eindhoven University About me Experimenting with APIs: Campus systems -> VIVO Visualizing campus research on multitouch tables using VIVO Library apps for ios/android Pure apps Home automation 2

3 Application Programming Interface What is an API Defines methods of communication between various software components The building blocks for developers and users to: Exchange data between systems Build upon or extend the functionality of software 3

4 APIs and the web The foundation of web 3.0 : offering resources to app/widget builders: Google Maps, Dropbox, Facebook, Twitter, ORCiD, Scopus, Web of Science Building new apps based on data from different sources (mashups). 4

5 5 Mashup example

6 SOAP : Simple Object Access Protocol Data goes in an envelope, harder to test because requests and responses need to be prepared/unpacked from the envelope. Pure server REST : Representational state transfer Easy to test in a browser by typing URLs and looking at the response: WSDL SOAP API REST API Web Service Description XML XML JSON XML: Extensible Markup Language JSON : Javascript Object Notation (new api only) 6

7 7 Object representation (properties) in XML and JSON

8 API use at Eindhoven University of Technology 8 Nightly transfer of publications to repository (using getchanges) Populating/updating our researcher profiles on the website (using getchanges) Populating the doctoral ceremonies agenda (based on thesis metadata: publication date, custom fields) (Green) Open Access alerting (metadata entered but no full text uploaded after x months) Embargo API 2018: new research website based on TYPO3 templates supplied with Pure data

9 APIs with public data should be open Researchers are also interested in the Pure API! Portability of personal output metadata and full text Create overviews and listings on personal websites Research data marketing: content versus branding Communication department: research data on website for university branding Researcher needs data for long term personal branding 9

10 The importance of CRUD Pure API = Read only Create : flexible import option Update and Delete : enable bulk editing using own tools instead of the client Protection against incorrect/malicious updates or deletes needed: Del *.* For expert users who can then build and share tools 10

11 Needed a tool for bulk fixing records with affiliation issues A bit too complex for a helpdesk script Not enough bulk tools, bulk import -> modify records doesn t work No CRUD Download Convert My case for an application based on the API: The Pure Exporter Combination of Pure API export and bulk import. Fetch publications from the API (using Pure Exporter) Convert to import XML using XSLT Perform changes on records using XSLT Import Import records using bulk import 11

12 12

13 13

14 14

15 15 If only

16 Old XML contained data from all linked entities New is less verbose but contains essential links to information (uuids) New API = more efficient development and faster responses Namespaces cleaned up Sandbox testing before development starts JSON parses faster from data to object (lists) Even faster by only requesting the fields you need 16

17 The new Pure API : versioning Old API: stable vs. current Stable: does not change often (definition?), should work always Current: has all the new stuff, might have some issues IT department: our policy is use stable Pure manager: but but I want to have all the new fields on our site/app! New api: versions A version for each major update (4) of Pure Each version available for a year Might be a bit too short for people used to stable Great for current users 17

18 Swagger Test API functionality before development starts The new Pure API : sandbox Easy authentication XML/JSON in- and output 18

19 19 Demo of the API on the TU/e installation

20 20

21 21

22 22

23 23

24 24

25 25

26 26

27 27

28 The new API is a huge improvement but 28

29 Some suggestions for the new API (based on experience) Enhancements: Fingerprinting functionality: searching for concepts and returning associated entities (persons, organisations, publications) -> makes excellent apps and websites! Facilitate global changes using CRUD : bulk import should be just another interface on the CRUD API Retain authentication when refreshing or stepping out of the sandbox Authentication for public data required? Accessible user data (tasks, activity) SPARQL endpoint -> semantic web 29

30 Some suggestions for the new API (based on experience) Configurable getchanges: Metrics update = change? Author/publisher/organization changed -> related publications TU/e mechanics check(ed) for changes every hour to update website Getchanges after a Pure update would run for hours blocking the website update Proposal: combine validation and change triggers Custom field sets Apply to validation rule Use as parameter in getchanges 30

31 Some suggestions for the new API (based on experience) Encourage development at customer sites Set up a developer community to connect universities and exchange knowledge, tools and apps Allow and encourage third party (mobile) apps : national search, manage research on the go, etc. 31

32 Thank you! Questions? 32