Subject: [CODE4LIB] Amazon product API will require a crypto signature

From: Jonathan Rochkind <[email-masked]>
Date: Mon, 11 May 2009 09:40:11 -0400

The Amazon products API keeps changing it's name, and has just been 
changed to Amazon "Product Advertising API" -- it's the one you use to 
look up books in Amazon and get metadata for them, though.

It looks from an email I got from Amazon that ss of August 15th, you'll 
need to cryptographically sign requests to this API, to have them 
responded to. It looks like kind of a pain.

I think a bunch of people on this list may be using this API. Beware. 
Instructions for how to cryptographically sign requests the way they 
want can be found here:

http://docs.amazonwebservices.com/AWSECommerceService/latest/DG/Query_QueryAuth.html
http://docs.amazonwebservices.com/AWSECommerceService/latest/DG/rest-signature.html

Like I said, it's looking like a pain to me. There are lots of details 
to get right. If you URI-escape not _exactly_ the same way they do, it's 
not going to work. Etc.

Jonathan

---

From: Tim Spalding <[email-masked]>
Date: Mon, 11 May 2009 10:31:26 -0400

They're also tightened up the API in various ways, and renamed it the
"Amazon.com Product Advertising API." Although I know of no case when
Amazon has shut down a library, it would be hard for any to claim
their site had "as their principal purpose advertising and marketing
the Amazon Site and driving sales of products and services on the
Amazon Site."

I think it's a terrible mistake for them. Their marginal cost is zero;
they don't need to do this. Data openness was a key factor in Amazon's
rise. And that was when thee were no other options. With viable other
options just emerging—Open Library, Google, at least—now is hardly the
time to make it less attractive.

Tim

On Mon, May 11, 2009 at 9:40 AM, Jonathan Rochkind <[email-masked]> wrote:
> The Amazon products API keeps changing it's name, and has just been changed
> to Amazon "Product Advertising API" -- it's the one you use to look up books
> in Amazon and get metadata for them, though.
>
> It looks from an email I got from Amazon that ss of August 15th, you'll need
> to cryptographically sign requests to this API, to have them responded to.
> It looks like kind of a pain.
>
> Instructions for how to cryptographically sign requests the way they want
> can be found here:
>
> Like I said, it's looking like a pain to me. There are lots of details to
> get right. If you URI-escape not _exactly_ the same way they do, it's not
> going to work. Etc.
>
> Jonathan
>

-- 
Check out my library at http://www.librarything.com/profile/timspalding

---

From: Jonathan Rochkind <[email-masked]>
Date: Mon, 11 May 2009 10:51:10 -0400

In fact, I believe that library-sector developers have asked Amazon and 
been told that their use is allowed. But definitely, there's no 
guarantee this will always continue be true. The terms of use don't seem 
to have substantially changed to me, but they could always start 
enforcing them more strictly -- for new accounts created to use the 
Product Advertising API, it looks like there actually will be a manual 
review step where Amazon staff approves you or doesn't, which never 
existed before.

So, while I'm still using it, I'm also keeping in mind what backup plans 
I have if they ever ask me to stop.

Here are the things I use Amazon API for, with alternates:

1) To take an ISBN, and look up more complete metadata for it.  
Alternatives:
    A) Google Books Data API (free for everyone; yes, there is a GBS API 
which is explicitly authorized for non-javascript access. GBS API will 
also allow you to find OCLCnums and LCCNs that correspond to an ISBN, 
when GBS has that data, which it often does thanks to the OCLC 
relationship.)
    B) WorldCat API (OCLC members)
    C) Books In Print API, although BiP seems to be making up their mind 
about whether they'll throw this in for free with an existing BiP online 
subscription, or charge extra for it.
    D) OpenLibrary? (Is this true?)

2) Cover images. Alternatives:
    A) CoverThing
    B) Google Books
    C) OpenLibrary

3) To find an ASIN, in order to make a link to the Amazon page.  
Ironically, this is actually what the API is _for_, and what Amazon 
would actually WANT you to do, but it's the thing that's least 
replaceable.  If you have the ISBN, and if you assume the ASIN is the 
same as the ISBN, you don't need an API.  This is often true, but not 
guaranteed to be true, and I think will become less true when the new 
ISBN-13 namespace starts to be used.   In my case, I use the ASIN to 
identify if Amazon has a search-inside and/or limited-excerpts 
available, but the API actually doesn't support that, I've been 
screen-scraping all along for that, once I have the ASIN.

---

From: Nate Vack <[email-masked]>
Date: Mon, 11 May 2009 09:56:10 -0500

On Mon, May 11, 2009 at 9:31 AM, Tim Spalding <[email-masked]> wrote:

> they don't need to do this.

Their marginal cost may be quite low, but I'm fairly sure it's not
zero. Cycles, storage, and bandwidth aren't free.

Amazon has never struck me as a stupid or capricious company --
witness the fact that they survived the .com bust. They've probably
thought rather hard about whether they need to spend developer cycles
and client goodwill before making this change.

Cheers,
-Nate

---

From: Jonathan Rochkind <[email-masked]>
Date: Mon, 11 May 2009 11:00:04 -0400

PS: If you do need to request a new API key, I reccommend when 
describing the purpose of your use, you make sure to emphasize adding 
links to Amazon to library pages. Which shouldn't be a lie, if you are 
indeed doing that. I consider adding such a link a reasonable 'cost' of 
using the API for it's other "side effects" too.  If they ever required 
me to _only_ include a link to Amazon and not to other vendors (as 
Google sometimes tries to do in their terms), then I'd stop using it.