Open connor-odoherty opened 5 years ago
@connor-odoherty Would you be interested in opening a PR for this? I'm all for providing mechanisms for people to access the API in a more cost-effective way, and if it's just a matter of making this one of the options that we include in the request, it seems reasonable.
I still prefer interacting with the Autocomplete API using the JS libraries, but this seems like a valid use case :+1:
@edwinwills Any thoughts?
Just to add a link to Google's documentation on how session tokens work https://developers.google.com/places/web-service/session-tokens
Out of interest, has anyone started any work on this?
Just to add a link to Google's documentation on how session tokens work https://developers.google.com/places/web-service/session-tokens
Out of interest, has anyone started any work on this?
Thanks for the docs link! As far as I know, no one's started working on this. Are you interested in taking it on? 😉
Digging into this more we discovered that in our use case using session based requests was actually more expensive, as our users are only locating suburbs and not street addresses which on average requires less characters typed
The Google Places API is expensive when charged for every single autocomplete and places detail request. Luckily, they have added Session pricing to their rate model.
To do this, users provide a session token that is used for every "group" of autocomplete requests. A "group" is considered to be a series of Places Autocomplete requests that result in a Place Details request.
So instead of being charged for every single request, and then the Places Detail request, you only get charged for the single Places Detail request so long as the proceeding Autocomplete requests shared the same session token.
A session token can be any string, though Google recommends UUID 4.
I suggest allowing the user to specify the session token on each call to the client through the options hash as opposed to setting the token during the initialization phase