See bottom of post for updates…
I’ve just finished a first draft of a JSON-based API for book data, created a test page and typed up some basic documentation.
Does this make code look sexy?
What’s the catch? The API is not intended for making backups or exporting your data to other programs. For that, use our CSV and TSV export functions, from the Tools tab. We are licensing the JSON API for browser-use only. This is about our data licenses. In-browser widgets have never drawn ire from our data providers.
Where can this go? This is just getting started. Everything can be expanded and improved. As members want new or different data, I will be only too happy to add it to the API. But the most interesting development will probably come from members, not LibraryThing employees.
I have created a LibraryThing API Development group to discuss the API, work through code and come up with new ideas.
At a minimum, I can see:
- New widget types, like widgets showing your most recent reviews.
- Widgets that take you to libraries, and other places other than LibraryThing. (Libraries have been clamoring for this for ages. Many use LibraryThing to feature new books on the website, and want the links to go to their catalog, not LibraryThing.)
- New result sets, for your tags or authors (separate from our books), your book’s works, series info, etc.
- Integration with other JS-based APIs, like Google Book Search.
What if I’m not a programmer? No problem. Come and LibraryThing API Developmenttell us what you want. We’ll help you, or maybe someone else will.
I’ve made some changes to the programming, changing how the code is structured and adding result sets for reading dates. We also have the first outside use of the API, a very promising—if not perfect—cover flip test by MMcM
). Follow what’s going on in the LibraryThing API Development