Which Google posts API query results can be stored in a database?

Question

I am learning the Google API, mainly the Places API. Since the number of requests to the Google Places API is limited to 100,000, I’m looking for ways to minimize the number of requests sent to the API. I was thinking about using a database to store previously received answers, so in the future I could get them without API requests and make an API request only if the necessary data was not previously stored in my database.

In accordance with the terms of use of the Google API, in particular section 10.1.3 Restrictions on copying or exporting data , it is not allowed to store data for an indefinite period, but it is legal to temporarily cache it:

You should not pre-extract, cache or store any Content, except that you can store: (i) a limited amount of Content in order to improve the performance of your implementation of the Maps API if you do it temporarily (and in no event more than 30 calendar days), safely and in such a way as not to allow the use of Content outside the Service; and (ii) any identifier or content key that specifically authorizes storage in the Maps API Documents. For example, you should not use Content to create an independent database of places or other local list information.

I believe that this section is not sufficiently explained. Can I store any data received by the API in my database for 30 days or only place identifiers? Because in some other contexts I read that only identifiers are allowed to be stored. I understood it this way: I can store ideas for an indefinite period, but I can use the data in just 30 days.

Since I only read about the Google APIs for a couple of days, I might have missed some deadline, so I would really appreciate it if you could help me.

Any suggestions on minimizing the number of API calls or sharing experience with real projects using these APIs will be greatly appreciated. Also, if you could offer me some alternative APIs that could provide similar functionality, it would be very helpful.

Thanks in advance!

Answer 1

From my experience with the Google Places API, your understanding is almost correct. Let me explain these two points in my own words:

i) Without prefetching or redistributing outside your application, you can cache API results for up to 30 days.

ii) You can use the place identifier or key in your specific application data, but nothing more (for example, if your application allows users to "register" places, you can save a list of place identifiers where they were a user object and search for places as necessary ID, but you can’t save a list of all places with Google names / details).

To reduce the number of API calls and speed up my application, I do the caching of neighboring calls in a simple cache, where the key is a lat pair rounded to a certain accuracy (so that calls within a certain radius fall into the cache), and the value is whole line of JSON result. Here is my code that runs on Java in the Google App Engine:

// Using 4 decimal places for rounding represents approximately 11 meters of precision // http://gis.stackexchange.com/questions/8650/how-to-measure-the-accuracy-of-latitude-and-longitude public static final int LAT_LONG_CACHE_PRECISION = 4; public static final int CACHE_DURATION_SEC = 24 * 60 * 60; // one day in seconds ... String cacheKey = "lat,lng:" + round(latitude) + "," + round(longitude); asyncCache.put(cacheKey, dataJSON, Expiration.byDeltaSeconds(CACHE_DURATION_SEC), MemcacheService.SetPolicy.SET_ALWAYS); ... private static double round(double value) { BigDecimal bd = new BigDecimal(value); bd = bd.setScale(LAT_LONG_CACHE_PRECISION, RoundingMode.HALF_UP); return bd.doubleValue(); } 

Regarding alternative APIs, I would suggest you look at the following:

Yelp API - provides data on bars / restaurants that Google lacks

Facebook API - easy to use if you are already using the Facebook SDK

Actual: Crosswalk Places - aggregates and normalizes place data from many sources, including Facebook and Yelp, but not Google

I am currently using the Google Places API, but I plan to add Yelp or Factual later to improve end-user results.