Background
I work on an app that among other things, allows to contact with businesses found via Nearby-search, navigate to them, visit their websites...
Once the user performs any action on a single business, it's supposed to be added to the recents-list, allowing the user to do it again, or see the information about the business again.
If the user called some business, next time he visits the recents-list, it should be shown there as a list-item, along with the name, phone number, etc...
Same goes if it was navigated to.
The problem
I've noticed in the terms a very big limitation of caching, saying that only the place-ID is allowed to be store permenantly, and the basic geographic-coordinate (lat-lng) can be stored for 30 days.
Weird thing is that it says it's ok to store only place-ID and coordinate, but I couldn't find what's the use of these if there is no mapping and context whatsover with them. And of course if you add context, you actually do store more information. For example, if you've called the place and showed the name, you already know both, so both should be mapped to the place-ID...
Links:
Caching. Customer can temporarily cache latitude (lat) and longitude (lng) values from the Places API for up to 30 consecutive calendar days, after which Customer must delete the cached latitude and longitude values. Customer can cache Places API Place ID (place_id) values
No Caching. Customer will not cache Google Maps Content except as expressly permitted under the Maps Service Specific Terms.
Applications using the Places API are bound by the Google Maps Platform Terms of Service. Section 3.2.3(a) and (b) of the terms states that you must not pre-fetch, index, store, or cache any Content except under the limited conditions stated in the terms.
Note that the place ID, used to uniquely identify a place, is exempt from the caching restriction. You can therefore store place ID values indefinitely. The place ID is returned in the place_id field in Places API responses.
What I've found
Sadly I couldn't find more information about this.
What I was told by someone is that caching should be fine for 24 hours as a part of "fair-use" to avoid re-queries of things that you already got, similar to how web browsers handle queries. This can help in case the user wishes to see information he already got just a few seconds ago, for example.
I was also told that if it's local on the user's own device, it should also be fine, as it's not published outside, and as the user could have saved the information anyway, manually.
For each of those claims, I couldn't find a reference.
This is very important here, as there has to be some mapping between the items on the "recents" list of the app and the actual place. For example, if it was a phone call, it has to at least have place-id (of the place) and the phone number (of the call). But it should also show the name of the place, as the user just showed this information and expect to see it there too, instead of just a phone number.
The questions
Weird thing is that it says it's ok to store only place-ID and coordinate, but what's the use of these if there is no mapping whatsover with them? What could I do with this exactly?
What is the fair-use of caching in this case?
Is it true that caching is ok in general for 24 hours, for all APIs ?
Can I also store in storage if it's very relevant as the user did something related to the query (dialed the phone number of the place, so should be possible to see this information right on the list, with other places)? I mean to store basic, relevant information I got from Google Places, for each recent-list-item ? Maybe I could set the basic information with an expired-date, while letting the place-ID stay, and when it's expired, only then to re-query?
Otherwise, it would mean the app will need to re-query all places each time the list is shown, to get a mapping between phone numbers and each place's information, and could easily cost a lot of money.