This is what I'm worried about too.
The API is _intended_ to be used as a client-side javascript.
_Technically_ it's of course possible to use it on the server side too.
But I am worried that this will run up against un-advertised Google rate
limits. I don't think it's a strict hits-per-day, I think it's heuristic
software meant to stop exactly what we'd be trying to do, server-side
machine-based access.
When I emailed Google to ask about this, all I got back was a statement
that this is only supported for client side Javascript access. I doubt
that users using software with this kind of in-browser Javascript access
enabled will run up against any problems with rate limiting. But I think
if we try to do it server side, we very well might.
Of course, there are many kinds of functions that are difficult or
impossible to do solely client side, especially integrating with
existing software. So this is a concern.
Interestingly, the Ex Libris SFX software demoing integration with
Google Books---as far as I can tell makes the API calls server-side!
Someone from Ex Libris confirmed to me that they have no special deal or
communications with Google. I think they didn't neccesarily realize they
might run into Google rate limiting (or even terms of service
violation?) issues. It will be interesting to see if they do or not. The
architecture of SFX would make it hard to implement Google Books API
access as purely client javascript, without losing full integration with
SFX on par with other 'services' used by SFX. We will see what happens.
Google's _stated_ (to me, in email; I got one reply, but couldn't get
them to reply to my followup) reason for only allowing client-side
access is that availability may depend on location, and they need to
know the end user's location (via IP address) to get accurate
availability for that particular end user. This could of course be
easily solved if the API URL format allowed the calling client to pass
on the end-user's IP address in the URL (&client_ip=x.x.x.x or what have
you). But I don't believe the Google Books API currently supports this.
I suspect that Google may have other "business model" reasons. Not sure.
Jonathan
Sebastian Hammer wrote:
> Is there any word on a limit to the number of hits per day on the Google
> API? I missed it in the docs if it's there, only saw an ominous warning
> that you might see the service temporarily disabled if you generated an
> 'unusually high number of hits' during development.
>
> --Seb
>
> Joe Atzberger wrote:
>> Impressive! As luck would have it, I'm working on the question of book
>> images in Koha this week...
>> --joe atzberger
>>
>> On Sat, Mar 15, 2008 at 3:14 AM, Godmar Back <[log in to unmask]> wrote:
>>
>>
>>> Hi Tim,
>>>
>>> I think this proposal suffers from the same shortcoming as
>>> LibraryThing's widgets, which is that only one per page is allowed. Aj
>>> better way may be to use spans and classes and keep the JavaScript in
>>> a library.
>>> I've attached the resulting HTML below; see http://libx.org/gbs/ for a
>>> demo.
>>>
>>> - Godmar
>>>
>>> --- index.html:
>>> !DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>>> <html>
>>> <head>
>>> <script src="http://libx.org/gbs/gbsclasses.js"
>>> type="text/javascript"> </script>
>>> <title>Simple Demo for Google Book Classes</title>
>>> </head>
>>>
>>> <body>
>>> <span title="ISBN:0743226720" class="gbs-thumbnail"></span>
>>> <span title="ISBN:0061234001" class="gbs-thumbnail"></span>
>>> <span title="ISBN:1931798230" class="gbs-thumbnail"></span>
>>>
>>> <span title="ISBN:0596000278" class="gbs-thumbnail"></span>
>>> <span title="0439554934" class="gbs-thumbnail"></span>
>>> <span title="OCLC:60348769" class="gbs-thumbnail"></span>
>>> <span title="LCCN:2004022563" class="gbs-thumbnail"></span>
>>> </body>
>>> </html>
>>>
>>> On Sat, Mar 15, 2008 at 2:04 AM, Tim Spalding <[log in to unmask]>
>>> wrote:
>>>
>>>> (Apologies for cross-posting)
>>>>
>>>> I just posted a simple way to get free book covers into your OPAC. It
>>>> uses the new Google Book Search API.
>>>>
>>>>
>>>>
>>> http://www.librarything.com/thingology/2008/03/free-covers-for-your-library-from.php
>>>
>>>
>>>> I think Google has as much cover coverage as anyone. The API is free.
>>>> Most libraries pay. I'm thinking this is a big deal?
>>>>
>>>> We'll probably fancy it up a bit as an add-on to our LibraryThing for
>>>> Libraries service, but the core idea can be implemented by anyone.
>>>>
>>>> I look forward to refinements.
>>>>
>>>> Tim
>>>>
>>>> --
>>>> Check out my library at
>>>> http://www.librarything.com/profile/timspalding
>>>>
>>>>
>>
>>
>
> --
> Sebastian Hammer, Index Data
> [log in to unmask] www.indexdata.com
> Ph: (603) 209-6853 Fax: (866) 383-4485
>
--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
|
