jennybc
commented
5 years ago cc @craigcitro
Thoughts?
Closed jennybc closed 4 years ago
jennybc
commented
5 years ago cc @craigcitro
Thoughts?
jennybc
commented
5 years ago From an alternative communication channel:
There is an API key use case, but it only applies to those internal to Google. Internally, there is a type of credential that is not associated with a project and thus still needs to be used with an API key for quota purposes. So you'd need to send token and API key. But this is not a general use case.
We are not set up for this 👆 and that's probably OK. When I work on request preparation, consider removing or reworking the existing API key code. If it stays, it should be connected to the AuthState and its mechanisms for setting and getting. Or perhaps the API key code should be removed.
hadley
commented
4 years ago Any thoughts on this? If things are currently working, I'd be inclined to leave everything as is, given the amount of development resources currently available for bigrquery.
jennybc
commented
4 years ago I would just leave this open. But I know you hate that.
But when/if/next time someone digs in here (e.g. validating against the Discovery Document as we do in googledrive and googlesheets4), we should get off this particular fence. Logic either needs to be added or taken away.
hadley
commented
4 years ago Given that no one has complained about this, I'm going to close, but we can resurrect if needed.
Current API key treatment comes from here:
https://github.com/r-dbi/bigrquery/pull/49
Is the BigQuery API usable with just an API key? Is there any point is sending one? I can't find any mention of API keys in current BigQuery docs.
If an API key is useful, I need to rework the gargle auth interface to also implement the API key.
If API keys are irrelevant, perhaps we should remove current API key code in the name of simplicity.