Useful and Usable Web Services

ELAG 2014
Building Useful & Usable Web Services
Steve Meyer, Technical Product Manager OCLC WorldShare Platform

(see also description of this talk)

API = a system of tools and resources in an OS enabling developers to create software applications. For data an example would be to create an aspirational view of what your data could look like, i.e. expose it as you want it to look like. Standards should be used to bring a clear understanding of your data model, serialisation and statements you want to make. Think of the community you're aiming at but also the one you want to belong to. A good standard will be stable.

sql is a way of creating api's. The language is not that distant from http commands (such as post, get etc.) to provide access to data. As api creator we can use any respectable programming language.

WorldCat metadata as case study. Is made of core assets with an intuitive api.Use of data modelling to carry out all sorts of tasks. Example of an api would be the validation of MARC record, with messages such as "008 must be present" etc.

Issues around authentication. When in a web service context, it's not a person you're authenticating. Access to a dataset by a machine is not without consequence. An api "key" allows me to enter but still need to provide identification. At OCLC try to provide equivalence api to web service after authentication (?)

Other issues: software is never perfect, documentation always with biaises...Ex. OCLC's api "holding availability", with intended use: connect a patron to a library that holds an item but actual use: read high volume holindgs info for analysis. Sometimes things go wrong.

Consider principles of useability in the way that you would in a unser interface context.

Questions:
Is it best to build api on top of your own system rather than someone else's? Yes though not always possible.
How to guarantee openess and re-sharing? Most OCLC api's are operational data, so we don't think about that. But we think of licencing and rights can be integrated in the data itself.
Who should write the documentation, the technical people, an editor etc.? It can be done as part of the process but mostly useful for highly technical people. Other option is to use people closer to the customers, such as product managers etc.