Stable currents

Developing against the Pure API

Nick Veenstra

About me

2

From public libraries into Library Information SystemsDevelopment (at INFOR and TU/e)

Research Information Specialist at Eindhoven University

Experimenting with APIs:

• Campus systems -> VIVO

• Visualizing campus research on multitouchtables using VIVO

• Library apps for iOS/Android

• Pure apps

• Home automation

• Application Programming Interface

• 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

What is an API

• “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

APIs and the web

5

Mashup example

6

SOAP API REST API

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.

REST : Representational state transferEasy to test in a browser by typing URLs and looking at the response:http://research.tue.nl/api/people/nveenstra

Pure server

XMLXML JSON

XML: Extensible Markup Language

JSON : Javascript Object Notation(new api only)

WSDL

Web Service Description

7

Object representation (properties) in XML and JSON

8

API use at Eindhoven University of Technology

• Nightly transfer of publications to repository (usinggetchanges)

• Populating/updating our researcher profiles on thewebsite (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

The importance of

CRUDPure 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

My case for an application based on the API:

The Pure Exporter

Combination of Pure API export and bulk

import.

11

Download• Fetch publications from the API (using Pure Exporter)

Convert

• Convert to import XML using XSLT

• Perform changes on records using XSLT

Import• Import records using bulk import

Needed a tool for bulk fixing 13.000 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

12

13

14

If only…

15

16

• Old XML contained data fromall linked entities

• New is less verbose but contains essential links toinformation (uuids)

• Namespaces cleaned up

• Sandbox testing beforedevelopment starts

• JSON parses faster fromdata to object (lists)

• Even faster by onlyrequesting the fields you need

New API = more efficient development and faster responses

• 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

The new Pure API : versioning

• The new Pure API : sandbox

18

• Swagger

• Test API functionality before development starts

• Easy authentication

• XML/JSON in- and output

Demo of the API on the TU/e installation

19

20

21

22

23

24

25

26

27

The new API is a huge

improvement

but…

28

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

Some suggestions for the new API

(based on 5.9.1 experience)

29

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

Some suggestions for the new API

(based on 5.9.1 experience)

30

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.

Some suggestions for the new API

(based on 5.9.1 experience)

31

Thank you!

Questions?

32