Alternatives to Amazon API

So the Amazon E-Commerce Service has changed it’s name to the Amazon Product Advertising API.  And it now requires an AWS account, and a cryptographic signature on requests.

There is a new terms of service, but according to the amazon email, “the terms are substantially the same,” and this is indeed true.  The requirement remains that applications using the API “have as their principal purpose advertising and marketing the Amazon Site and driving sales of products and services on the Amazon Site.”  This wasn’t a requirement Amazon seemed particularly interested in strictly enforcing before. I have no particular reason to think this will change, but the changes to the API in general give reason to be cautious.

Especially one new change: it looks like new requests for API keys will actually be manually reviewed and approved.

So, it’s prudent to start identifying what I’d do if I’m no longer able to use the Product API. There are actually three main things I currently use the Amazon API for in Umlaut (and therefore in any of my other software that uses Umlaut services, such as my OPAC).

Resolving ISBNs

It’s extremely useful for Umlaut to be able to take an ISBN, and look up author/title/etc metadata corresponding to that ISBN.  Umlaut historically used the Amazon API to do this. But there are other options which work quite well, although interestingly none of these services I’ve tested actually respond as quickly as Amazon, not even the Google one.

Google Books API

Quite usefully, the Google Books Data API will also allow you to accomplish this as a byproduct of it’s functionality. You can look up a record in GBS by ISBN, and you get back a nice Atom response with author/title/etc.  Nice.  Theoretically, the GBS documentation suggests that you might also get a corresponding LCCN or OCLCnum in there, but in fact the GBS Data service doesn’t seem to currently ever provide this. Maybe in the future, would be nice.

I have already enhanced the Umlaut GBS plug-in to make use of this information from GBS, done and done, backup plan in place. The GBS Data API is free for anyone, with no usage quantity limitations so far as I know.

Not sure how GBS’s coverage of all ISBN compares with Amazon’s, but I expect it compares pretty favorably, especially with the OCLC/Google cooperation to add many/most/all WorldCat records to GBS.

Worldcat APIs

The WorldCat API would also probably allow you to do this.  But it’s available for unlimited usage quantity only to OCLC members. (update 19 Aug 2009 — I believe that non-OCLC members are invited to ask permission for unlimited usage of WorldCat API, and I’ve been led to believe that permission will generally be granted, at least if they don’t think your app competes with OCLC services. It’s worth a try. Interested in hearing about anyone that does this and gets approved or not.)  It’s also a bit slow.  There is also some limitations on data fields returned if your app can’t guarantee the end-user is affiliated with your institution, which Umlaut is currently unable to do (Umlaut hasn’t needed to care before).  I’m not sure if those affiliation limitations would matter for this use though.  I’d also probably want to look at MARC records from the service, rather than DC or Atom records, to take full advantage of all the data WorldCat could give me, but dealing with MARC is kind of a pain.

So overall, not quite as convenient or easy to use as the GBS API for this purpose, but I’d still like Umlaut to make use of it at some point, when I or someone else has a chance.

WorldCat’s coverage of the ISBN universe is presumably pretty good.

Open Library API

I believe it should be possible to use the Open Library API for this too, but I haven’t had time to fully investigate. The Open Library recommended API keeps changing, hard to keep up with. Not sure what Open Libraries current coverage of the ISBN universe is, or if Open Library will actually reliably allow you to look up records it does have by ISBN.This would be good for Umlaut to explore at some point too.

Bowker Books In Print XML Service

Bowker Books in Print has a newish XML web service to allow you to do exactly this, look up an ISBN and get metadata back.  But I’m still confused about the pricing model for it. It may be that the web service is available at no additional charge to institutions already subscribing to an unlimited-seat license to BiP online.  But it may be an additional charge, not sure.

The Bowker database presumably would have as good coverage of the ISBN universe as is available anywhere, since Bowker is the US ISBN registrar (which is not to say that BiP only includes US titles; just that Bowker is pretty involved in ISBN infrastructure, so presumably has good coverage).

If it’s available to existing BiP subscribers at no additional cost, that’s enough potential users to justify someone spending time adding this to Umlaut, if someone has time. If it’s an additonal cost — well, there are other sources of this information available at no additional cost to anyone, or in one case to OCLC members.

Cover Images

Another thing many of us use the Amazon API for is cover images. Fortunately, there are now a variety of other sources for cover images, although none yet probably have the range of coverage of Amazon, they’re all getting better. And cover images are, to me, really just an extra bell/whistle, not really crucial.

• LibraryThing: Umlaut already consults CoverThing for cover image availability. Not great coverage, but worth checking anyway.
• Google Books Data API:  The Google Books Data API will also give you cover images.  And awesomely allows you to look up books by OCLCnum or LCCN too, not just ISBN; I don’t think any of the other services do this. It’s coverage is currently quite expansive,  but a significant portion of ‘covers’ it returns will actually be scans of title pages, and there’s no way to tell that’s so. But, hey, a scan of a title page is pretty good if you’ve got nothing else. Umlaut currently already uses cover images found from GBS.
• OpenLibrary: Open Library’s got covers too. Not sure how expansive their coverage is. Umlaut kind of sort of uses OL covers, but it uses an outdated API (that was all that was available when it was written) that doesn’t actually find most OL covers. It needs to be updated.
• Wikipedia/dbpedia.  Wikipedia’s got some covers, but the coverage is currently not very expansive. I expect it to keep getting better though. The dbpedia interface to wikipedia should, I think, make it possible to query for and find covers in an automated fashion. Would be interesting to experiment with.Interestingly, since  think most publishers are actually interested in providing their covers to anyone who wants to display them, it would be an interesting project to try and set up a regular automated feeds of covers from participating publishers into freebase. I think that’s probably the cover image source of the future, eventually.

Links to Amazon

Ironically, the most irreplaceable aspect of the Amazon API is the one that actually serves Amazon’s interests, and they wouldn’t want to see go away!  The ability to figure out the ASIN for a book knowing it’s ISBN or other characteristics, and thus make a reliable link to the Amazon page for the book.  (Umlaut also uses the ASIN to identify if a book has “search inside” or “limited preview” functions available, although Umlaut actually screen-scrapes (once it has the ASIN) to determine this, there’s actually no API support for it. This is an awfully useful thing to be able to tell my users, I hope Amazon doesn’t put anything in place to stop my screen-scraping).

Now, if you have an ISBN, you can guess that the ASIN is the same as the ISBN (converting to ISBN-10 first if necessary).  In 99% (100%?) of the cases, this seems to be a safe assumption. But it’s not actually guaranteed — and I expect that when 979 ISBNs come into force, this will no longer be true, as the ASIN is 10 digits, and formed from a 10-digit ISBN.

So, if the Amazon API becomes unavailable to me, this is the one thing I would not be able to do, at least not with books whose ISBN’s don’t correspond to ASINs.

That’s actually the reason I suspect Amazon won’t tell libraries to stop using the Amazon API. They want us to link to their pages,  don’t they?