Introducing the LibraryThing books API
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.
What is this for? The API gives you Javascript access to your book data. The most obvious use of this would be to create new, much better widgets. At first, we expect this to interest programmers, but as new widgets are developed, non-programmers will get cool things. I started by redoing our traditional widgets in a new way here. That's the base, not the ceiling!
How does it work? Every user can retrieve their data, in JSON format—basically as a ready-made JavaScript data structure. You control what is returned—books, tags, ratings, etc.—how it's sorted and so forth. By default we give you a standard library of functions to parse and display the data. You can use it, build on it or start from scratch. Find out more here.
What's great? All our code for processing the JSON API has been and will be released as open source—available for use, reuse and modification. Better—since we're not the best programmers, particularly in JavaScript!—we are requiring any software that builds upon the API to be released under similar terms, so everyone can take advantage of improvements and advances.
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:
UPDATE: 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 (here). Follow what's going on in the LibraryThing API Development group.
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.
What is this for? The API gives you Javascript access to your book data. The most obvious use of this would be to create new, much better widgets. At first, we expect this to interest programmers, but as new widgets are developed, non-programmers will get cool things. I started by redoing our traditional widgets in a new way here. That's the base, not the ceiling!
How does it work? Every user can retrieve their data, in JSON format—basically as a ready-made JavaScript data structure. You control what is returned—books, tags, ratings, etc.—how it's sorted and so forth. By default we give you a standard library of functions to parse and display the data. You can use it, build on it or start from scratch. Find out more here.
What's great? All our code for processing the JSON API has been and will be released as open source—available for use, reuse and modification. Better—since we're not the best programmers, particularly in JavaScript!—we are requiring any software that builds upon the API to be released under similar terms, so everyone can take advantage of improvements and advances.
Does this make code look sexy?
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.
UPDATE: 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 (here). Follow what's going on in the LibraryThing API Development group.
Labels: api, apis, books api, javascript, json, member projects
posted by Tim at 1:38 AM
5 Comments:
First reactions:
- you really should separate this into two requests - one for the standard libray (which takes limited parameters - perhaps just a version number), and then a quite separate request which produces the JSON data. (Think of applications that make multiple requests on the same page - currently they will have clashing copies of the code you try and serve with each set of data).
- study how other APIs do namespacing - basically have one global object which contains all your functions, so calls take the form LibraryThing.coverImage(), rather than having the prefix LT_API_
- actually the API isn't very useful, since it simply tells the user about the books some particular user has, given their (laregly secret) ID. Where are the useful API calls such as given an ISBN tell me about the book; find all books matching certain criteria; find the id's of users who have a certain book etc. The real innovation in using APIs comes when the connections between the data can be explored - and this API does not allow any of that to be used
Whilst I see what you are trying to do with the licence, it goes further than any licence I have come across, and will I think make many programmers stay well away from the API. When you licence data, it's most unusual (and probably unworkable) to impose licencing restrictions on the code that accesses that data.
What I think you should look at is:
- the LibraryThing library can be open source
- the data can be licenced how you see fit (for example "no commercial use")
- code that processes the data is unfettered - thats the way to get real innovation in the way people use the data. Many will choose to share their techniques, but forcing it will simply make them avoid it.
I replied here: http://www.librarything.com/talktopic.php?topic=40692
I know nothing about code and what not, but that cover flip is all sorts of amazing.
Very nice to see new development, but, can current supposed functionality be fixed?
I've posted and emailed several times about the fact that RSS feeds from an individuals tag's are not working, and they are still broken, unless I'm missing something terribly obvious.
The RSS feeds are a great feature, but, not if they are broken, and I'm a little disappointed to have received not one bit of email feedback on this problem from the staff I emailed. Someone please help!?
Thanks, /Nick
Ooh, I like wiidgets!
Post a Comment
<< Home