Google's API terms of service prohibit the caching of API results for longer than their cache header:
<snip> Prohibitions on Content Unless expressly permitted by the content owner or by applicable law, you agree that you will not, and will not permit your end users to, do the following with content returned from the APIs: Scrape, build databases or otherwise create permanent copies of such content, or keep cached copies longer than permitted by the cache header; </snip> Google API requests usually return with a 7 day cache header set. So, in theory, there should be logic to clear the cache on a regular basis. However, I'm not sure how often Google enforces their API terms... I'd imagine other API services have similar, or perhaps more restrictive, terms as well. That's why it was decided we're not to use Amazon to for cover images. Also, check with publishers for artwork. Elsevier, for example, provides cover images for journals which can be used in your catalog. http://www.elsevier.com/journal-pricing/journal-cover-images We use Google APIs and publisher provided images to provide cover art for our catalog. It works pretty well for popular titles, but falls short for the majority of our holdings. -David -- David Lee (608) 890-1912 Shared Development Group - UW Madison General Library System On Nov 5, 2013, at 9:23 AM, Joshua Welker <wel...@ucmo.edu> wrote: > I built something similar using Google Books. You'll definitely want to > create a mechanism for caching the cover image URLs or else you are going > to run into the API's daily limit (which is 1000 by default I think). An > easy way to do it would be to store the URL and an identifier such as a > bib record number or ISBN as a pair in a Solr index or SQL database. When > the page loads, you can have either the client side or the server side > fetch the image URL based on the current identifier number and display it > on the page. > > I built a new books display using Google Books that shows an automatically > changing feed of recently added books. I ended up creating a script that > runs each day, and rather than indexing the image URLs it generates a > static HTML page for the display, which contains all the complex > formatting so that it doesn't have to happen with each page load. You can > see it here: https://library.sbuniv.edu/new-books/ > > > Josh Welker > > > -----Original Message----- > From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of > Adam Wead > Sent: Tuesday, November 05, 2013 9:14 AM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: [CODE4LIB] display book covers > > Hi all, > > Anyone have some good resources about tools for gathering book cover > images? I'm building that into our next catalog update, which uses > Blacklight, but I'm not necessarily looking for Rails-only approaches. My > questions are more general: > > What sources are out there? (ex. Google Books, amazon) > > Making it work? > I'm trying out Google Books at the moment, just making a call to their > API. This can be asynchronously and loaded after the rest of the page, or > cached, perhaps even store the url in solr or a database table? > > Tools? > I am trying out a Google Books gem[1], which is just a wrapper for the > api. > > Other thoughts? > > Thanks in advance, > > .adam > > ______________________________ > Adam Wead > Systems and Digital Collections Librarian Library + Archives Rock and Roll > Hall of Fame and Museum > 216.515.1960 > aw...@rockhall.org > > [1] https://github.com/zeantsoi/GoogleBooks > This communication is a confidential and proprietary business > communication. It is intended solely for the use of the designated > recipient(s). If this communication is received in error, please contact > the sender and delete this communication.
smime.p7s
Description: S/MIME cryptographic signature
