Modularizing Our Code and Making it Reusable
One of the most common things that my technology colleagues grumble about is the fact that they can’t get to status/item information from their catalogs. This is often because the ILS vendors don’t provide an API to this data. The result is that this information has to be screenscraped. Nearly every NextGen resource discovery tool does this, whether its Blacklight, VuFind, WorldCat Local, or Summon. There are two problems with this. One is that this code is application specific. Two creating this kind of code is not for the faint of heart. Yes one could look at the code and steal the screenscraping bits. I think that it would be much easier and better if this stuff was available as an API/Web Service.
You all nod and say “yes Karen I’d like to have a dragon to guard my house too but I don’t live in fantasy land”. Okay, I know. Who knows, when or if all library vendors will provide an API to this data. But if we’re going to go to the trouble of writing screenscraping code why don’t we write code which is modularized, acts like a RESTful web service, scrapes the data and presents it in an API form instead of coupling the code to a specific tool or kind of tools? That way when ILS vendor XYZ decides they are going to change their interface we only have to fix this in ONE PLACE not across multiple systems/platforms/tools. One could then focus on fixing the problem in a generalized sense not in a particular context. Plus you have more collective eyes potentially on the problem. By doing this we also make the data usable in lots of different ways, some of which we probably haven’t thought of yet. Moreover the data is also available to developers and geeks who aren’t in libraries and may find some nifty not thought of way to use it. Lastly, libraries that don’t have the coder talent to create their own screenscaping can use the service to get at this information from their catalog.
So folks? What do you think? Can we just make a Item Information web service please that works with all ILSs? Then everyone can just use it to provide this info instead of writing/maintaining their own screenscraping code.
I think a common specification is the goal of Jangle. To me, though, it is symptomatic of any project that tries to be a catch-all: it introduces too much overhead to be truly useful. I’d rather just have a multi-format API (whether by screenscraping or other means) that lets me get catalog information in JSON, RSS, and the various OpenSearch formats. The exact format of the output data isn’t all that important — I just want it yesterday.