Today we announce the creation of a new Web Services API for Common Knowledge. See the blog post for more eloquent prose than I can spit out.

In the meantime, check out the LibraryThing Web Services API documentation, complete with sample requests and responses. You'll also notice a new link to the API documentation in the bottom bar.

With the new Web Services API we have a modular mechanism for expanding our open data offerings. This modular design makes it easier for us to give our data away and makes it easier for you to create programs that use it.

Message edited by its author, Aug 1, 2008, 2:15pm.

I think it would be better if author/name were in last, first format or both were available.

I think person/url is superfluous. Or did I miss a case where it isn't trivially derived from person/name? (The work and author urls I see more justification for, even though the id is right there.)

MMcM, I think we want to spell out any attributes that we might want to change (like any URL links back to LT) rather than have them be derived.

Correct. Applications shouldn't have to do URL logic on their end.

As for the author name. That's something that we talked about. I'll look at changing it (or adding the other format). It's another issue of trying to allow less logic on the applications side. Flipping names can be more complex than first thought.

Will the CK key be different than the JSON key some of us are already using?

Yes, the Developer Key—for us in CK—is supposed to be a hidden thing. You can only use it an unlimited number of times per day, and it ties your agreement to your use—like an Amazon key, or a Google Maps key.

The JS key is public when you make it so—of necessity, because JS is always public. It basically allows access to your data.

I've been thinking about the keys for the last two days and I'm going to have to talk with Tim about them. We may have to change the web services keys to a different sign-up structure. I want to make the change before the API gets too ensconced in developers' workflow. It won't be a real change in the code for now, mostly in the sign-up process.

Let Tim and I talk it over and I'll report back as soon as I know something. In the meantime code away and let us know if you do something cool with it.

Oh...and in message 6 above, Tim said "You can only use it an unlimited number of times per day..."

I think he meant to say that you can only use it a limited number of times per day. Right now that is 1000 queries but we'll play that by ear and change it if it looks like it needs to be changed.

Chris: Take a look at the sign-up process. It wasn't working at all—it forwards to one of the "developer" pages. I pushed them, and then had to change them to forward back to the services pages. It works but it's just wrong too, and you had intended services to do everything, but something didn't get changed right.

I'll take a look at them and get it straightened out.

I think if I was giving examples, I'd be inclined to use the ISBN rather than work number - the work number could change with combining/separating.

Ah...good point. I'll change the examples. Although that brings up another entirely different conversation about combining. We'll get into that a different time. :)

Chris: Are you doing the wild-goose-chase on combined works. If not, talk to me. I know you don't know the combination system—gladly, I suspect.