One of the goals of Open Library is to make it easy to share bibliographic data. While we’ve had various APIs available from the very beginning and have made bulk data dumps available since forever, there is always room for improvement.

We’re working on 2 new APIs at the moment, and today, we released a tiny baby version of our new Read API. The upcoming Import API was also released for internal use only, deployed as a replacement part for the process Open Library uses to discover new books (and their accompanying MARC records) that are scanned each day by the Internet Archive. (More on the Import API later.)

The Read API
Similar to the way our existing Books API mirrors and is compatible with the Google Books Dynamic Links API, the Read API is very much inspired by, and partially compatible with, the Hathi Trust Bibliographic API.

The idea is, you can hit the Read API with an identifier or a series of identifiers or an array of identifiers, and it will tell whether there is a readable or borrowable version available through Open Library. As you render a page in your own bookish website, you can paint links into Open Library based on the response.

Traversing Works and Editions
The Read API will try to match your identifiers to an OL edition record, and will then return its work and then other editions of that work which also have readable or borrowable resources if the one you’re looking for doesn’t have an available eBook. That way, you can at least point people to a similar version of what they were looking for if the initial query doesn’t find something to read.

I find myself wondering whether this functionality might be useful for other things, like reconciling works data across different systems, or comparing edition fidelity/duplication.

We were thrilled to bits to meet Dan Scott a little while ago when he came to visit us at 300 Funston. He’s a hacker on the Evergreen ILS system, and by day works at Laurentian University. Evergreen’s already been using the OL API for showing covers and tables of contents within their UI, but it was somewhat laborious, needing to blend two of our APIs together to get the desired output. It was great to meet Dan, and we actually ended up designing the Read API response together over the course of an afternoon, specifically to remove that double-step process. Dan has written about this too: The Wonderful New Open Library Read API and Evergreen Integration. The super thing about working with Dan is, once we’ve dotted the Is and crossed the Ts on this, it can be deployed to any and all instances of Evergreen that want it. (Hello, Koha? I’ll be in touch shortly!)

So, there are some initial Read API docs in the Developer’s area, and see a working demonstration of it that Dan & Mike hooked up in a flurry of late night emails and tweaking (which was a pleasure to observe). Head over to the Open Library skin on the Laurentian University’s library catalog to see very young API in action!

The obvious caveat is — as Dan notes — “working code wins,” which is another way of saying we haven’t optimized or scaled anything up for a bazillion hits yet, so results will be a little slow for now. But still! Books! In your catalogs! If you are from a large system that would probably send us a bunch of requests per second, it would be nice if you could give us a head’s up if you’re going to use the Read API. A good place to do that, or ask questions is on our ol-tech mailing list.

By the way, as you may have noticed, a few weeks ago, we mentioned that oclcBot has updated the Open Library with about 4 million OCLC IDs too, which means that if you speak OCLC, you can hit the Read API with your OCLC ID to look for things to read or borrow through Open Library on your site.