The client code inherited a scheme for plucking out query headers that seem like they are intended to be in the headers.
That is done in parse_query_and_convenience_headers at
https://github.com/looker/looker-sdk-ruby/blob/master/lib/looker-sdk/client.rb#L458-L462
The specific headers it supports are:
CONVENIENCE_HEADERS = Set.new([:accept, :content_type])
It isn't clear that this is doing anyone any good. And, there have been a couple known instances of this being a pain for people.
Because Looker API designers were not precluded from using these strings as query param names, there are some endpoints in Looker that use content_type as a param. Those endpoints are thus confusingly difficult to use from the SDK.
The workaround is to explicitly declare the query parts like:
Instead of:
sdk.foo({content_type: 'bar', baz: 1})Use:
sdk.foo({query: {content_type: 'bar', baz: 1}})The SDK allows for explicitly saying which params are for the query part and which are intended to be headers. So, one can still do:
sdk.foo({query: {content_type: 'bar', baz: 1}, headers:{content_type: 'json'}})Nevertheless, my proposal is to simply remove the CONVENIENCE_HEADERS stuff so that the only way to have hash members end up in the headers is to do it explicitly.
Yet another case of the 'helpful' name-specific handling getting in our way more than helping us.
The client code inherited a scheme for plucking out query headers that seem like they are intended to be in the headers.
That is done in
parse_query_and_convenience_headersathttps://github.com/looker/looker-sdk-ruby/blob/master/lib/looker-sdk/client.rb#L458-L462
The specific headers it supports are:
CONVENIENCE_HEADERS = Set.new([:accept, :content_type])It isn't clear that this is doing anyone any good. And, there have been a couple known instances of this being a pain for people.
Because Looker API designers were not precluded from using these strings as query param names, there are some endpoints in Looker that use
content_typeas a param. Those endpoints are thus confusingly difficult to use from the SDK.The workaround is to explicitly declare the query parts like:
Instead of:
Use:
The SDK allows for explicitly saying which params are for the query part and which are intended to be headers. So, one can still do:
Nevertheless, my proposal is to simply remove the
CONVENIENCE_HEADERSstuff so that the only way to have hash members end up in the headers is to do it explicitly.Yet another case of the 'helpful' name-specific handling getting in our way more than helping us.